Unit Test Coverage

One of the fastest ways to get promoted in certain environments is through attrition. When a key player leaves, someone needs to step up and take over their work, somehow.

Well, at Antonio‘s workplace, the tech lead on several projects abruptly quit. This sent the Project Management Office into a spiral, as that one developer’s tasks were on every critical path on their Gannt chart. This four-alarm panic escalated all the way up to the C-suite.

And that’s how Antonio and a bunch of other developers got pulled into a series of meetings to turn them into “bug hunter-killers”. Garth, the head of the PMO, laid out their mission.

“The root cause of the bugs are architectural flaws which have not yet been addressed. So we need a team that’s going to go in, and salvage this project.”

“Are there any unit tests?” Antonio asked. “Before we go on a big refactoring push, we should make sure we’re not introducing regressions.”

“Oh, don’t worry about that. Our CI system is configured to reject builds under certain levels of coverage.”

So Antonio dug into the code. The project was in Java, and pretty much every class was built using Lombok- a library that handles a bunch of boring stuff, like implementing constructors, toString and equals methods. With that in mind, let’s look at their expansive code coverage in their unit tests:

    @Test
    public void shouldBeNotNullAndTestHashcode() throws ParseException {

        Entity Entity = factory.manufacturePojo(Entity.class);

        assertNotNull(Entity);
        assertNotNull(Entity.toString());
        assertNotNull(Entity.hashCode());

    }

    @Test
    public void testTrueEquals() {

        assertTrue(new Entity().equals(new Entity()));
    }

    @Test
    public void testFalseEquals() {

        Entity Entity = factory.manufacturePojo(Entity.class);
        assertFalse(new Entity().equals(Entity));
    }

Entity has been anonymized, but in practice, this is the model for the majority of their unit tests: they test the code generated by Lombok. This keeps their code coverage metric pretty high, but unfortunately, doesn’t actually test anything.

The “architectural flaws” the PMO is concerned about are mostly of the form “a sole developer did a rush job under changing requirements and unreasonable deadlines and the code is just a plain mess”. Between that and no real tests, the PMO is going to have to learn to love the sound deadlines make when they fly by.