DEV Community: Alexandra Marin

The coverage report is a lie

Alexandra Marin — Mon, 15 Apr 2019 06:57:59 +0000

Having had to work without code coverage tools made me think they created beautiful code. When the opportunity finally came I was overjoyed, but let’s just say plot twists were about to unfold very soon after I got to work 😅

What is a coverage report anyway?

A test coverage report is a collection of stats on our production code generated each time the test suite runs.

The stats show the number of production code lines executed by tests. The higher this number is, the more source code is insured by tests. Uncovered lines have a higher risk of change, therefore are good candidates to test next.

Sounds great! How could anyone misuse it?

Glad you asked!

The easiest trap to fall in, of which I have first hand experience, is trying to game the test-driven flow to get a high coverage percent. When focus shifts from modelling and code design, it’s likely to end up with full coverage but junky code.

Another concern is some management sees it as proportional to the trust one can have in production code. Over-reliance on the coverage percentage gives a sense of false security. Misinterpreting coverage reports can hurt the trust in the engineering team.

Oh no! How do I fix it?

Focus on test quality rather than the quantity. Just because we have tests does not mean they are the right tests. A good unit test can tell if a change in the codebase breaks requirements.

Correct analysis of reports can guide next coverage efforts, considering the limitations and supplementing with other metrics.

Multidimensional quality metrics are fantastic to break dependency on coverage reports. The more sources of metrics, the better informed our decisions are.

Additional metrics can include cyclomatic complexity, tracking the number of errors relative to the number of tests and code visualisation tools – and the good news is they come in other automated tools and services, relatively easy to set up and integrate in the normal workflow.

Document legacy code with characterization tests

Alexandra Marin — Tue, 12 Mar 2019 07:42:48 +0000

We’ve been assigned work on legacy code. The maintainer is no longer around and we have no clue how the system should behave. What’s the safest way to go about it?

First we need to learn what the code we’re about to change does. After we make our changes, we compare the resulting state against the initial one to verify that we introduced only our intended changes.

We can get a snapshot of the initial system behaviour using characterization tests. Characterization tests help reverse engineer specifications and are a trustworthy source on system behaviour.

Here are the steps to adding a characterization test to a legacy codebase.

Formulate a hypothesis – We choose a unit or behaviour we want to investigate and add a test to exercise it.

Assert it – We purposely write a failing assertion and let the test output tell us what the correct output / behaviour is.

Get a clear picture of the system – The test retraces our steps and it’s replayable. Any future change we’ll make will be compared to this snapshot so we can be sure we did not introduce defects.

Characterization tests serve as documentation for other folks that need to interact with the code and minimise the time it take to share expertise.

They’re also entertaining to implement – the process is somewhat like detective work, where we investigate different hypotheses to understand what the code actually does.

Characterization tests are great to implement in legacy codebases from the first moments when we’re still learning about the code and they’ll provide value even later on because they sustain refactoring efforts without introducing defects.

Programming language trends as shown by job postings

Alexandra Marin — Fri, 01 Sep 2017 15:44:52 +0000

The idea came from recognizing that working in tech means working in a dynamic and fast-paced environment. Things are always changing and the ability to keep learning can make a difference in your career.

In fact, the Pragmatic Programmer book recommends learning at least one new language every year.

So with this in mind, I set out to answer the question of what should I learn next. And what better way than to reverse engineer the job market to see the most requested programming languages.

And so, I was ready to start building the prototype.

Building the prototype

I imagined it being a web app, so my first challenge was a technical one: (re)learning the necessary tools for web development. I chose to learn Angular and struggle with the Plotly JS documentation in order to make the frontend. As for the backend, I had to get reacquainted with ASP.NET and Azure, after a break of a few years.

But the more interesting challenge came from a design and data visualization perspective. As opposed to other tools with higher data density that also caused more noise when displaying it, I made a conscious decision to have minimal (read clear and uncluttered) presentation that would offer a fast answer, even though it meant showing less data.

The result

Without any further ado, here’s the result:

Tech stack

Going a bit into the technical details, the prototype ended up being a web app living in the cloud. The frontend is written in Angular and PlotlyJS and the backend is a cross-platform C# web API uploaded in Azure. The app data is stored in an Azure SQL database and synced via an Azure web job.

A cron job runs once per month, polling the HackerNews API for all the jobs posted in the previous month. It then feeds them to an analyzer which labels the with the correct keywords and stores the results in the database. From the website end, Angular makes a request to the C# backend which reads the stats from the database and returns the results to be displayed by PlotlyJS.

What did I learn?

Start small. I had a huge list of features I wanted to do, but I decided against it. Instead I went for building the minimal core feature and validating the idea. Any changes I’ll add will happen in small increments.

Don’t use beta versions of your tools. I got bitten by (1) trying to use .NET Core before it was ready and (2) uploading it to Azure and hoping that they playing along, since they’re closely related (they didn’t like each other at all). Also stumbled upon a weird Entity Framework cross-platform bug, which was quite unexpected since I’m always assuming that any bugs would come from my code only.

Carefully choose your data source , because it will impact your results. I get my data from the HN API, so the extracted trends will hold (mostly) for startups and developed countries.

Mind your external dependencies. Some months, the thread is posted later than expected, so the last lesson would be to have fail-safe mechanism whenever dealing with external dependencies.

The future

Already have a list of planned features including extending the visuals to frameworks, showing a particular’s language evolution over time, making comparisons, etc. I’m most excited about trying to make predictions about what’s going to be popular next month or next year.

Thanks for reading!