“I was hired as a ‘best practices consultant’ to help bring a 300-developer company’s development practices into the 21st century,” wrote Ian, “and after six months, I had failed.”

“Our first objective was to introduce automated unit testing. They had all sorts of horribly interconnected code, and the tests would help reduce the fix-here/break-there problems. However, after many, many tutorial sessions with developers, and quite a few long meetings spent trying to convince them of the benefits, no tests emerged. The developers stubbornly held that testers should test code, not them.”

Ian continued, “Adding some teeth to our policies, we set-up a continuous integration server that emailed everyone reports of unit test code coverage. This way, managers could take responsibility for getting their teams to write unit tests. That seemed to do the trick: the number of unit tests and code coverage started to steadily climb on all projects.”

“I finally felt that all my efforts were worthwhile,” he added, “the overall health of the team’s code would now increase immeasurably. Less bugs, less time manual testing, and all that good stuff. And then I started to look at the unit test code.”

public class StaticDataRequestTest {

    @Test
    public void startClientReqest() {

        try {
            new StaticDataRequest().onData(null);
            assertEquals(
                " processing client static data request  ",
                true, 
                true);
        } catch (Exception ex) {
            assertEquals(
                " processing client static data request  ",
                true, 
                true);
        }
    }
}

Ian added, “I guess we got what we asked for.”

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!