That Time I Wrote Unit Tests for the Development Team

A Separate Test and Development Team

There is some value in having a separation in those who develop software and those who test it.  The idea is a fresh set of eyes on requirements may mean the tests catch something that was implemented incorrectly in software due to a misunderstanding of requirements.  Testers sometimes understand the bigger picture of how a whole system works rather than a more focused feature within the system.

However, in some environments, you have the ‘throw it over the wall’ syndrome.  In a nutshell, it means that once a group is done with their work, it is someone else’s problem.  In the case of software and testing, some developers can finish their software then ‘fling’ the compiled result (usually a heaping pile of crap) to the test team.  The support for fixing that code once issues arise is usually not very good (of course, I am describing the worst case here).  There can literally feel like there is a fence between the testers and the developers.  Once something is chucked over the fence, it doesn’t come back.  No support… you are left on your own.

Fence

My Position As the Guy Who Writes All the Unit Tests

There was not a lot of guidance in my unit testing position – mostly it was a ‘Hey, go test this section of code’.  I wanted to be able to show my progress of unit testing at a moment’s notice, so I took a while to setup a Jenkins server.  This first meant automating the builds (Qt code).

Tools

Once the code built automatically within the Jenkins server, I wrote a single unit test and wrapped it with GCOV coverage statistics.  Every time the build executed, I could show code coverage from my unit testing.  Over time, I could show that number go from 0%, to 10%, to 50%, and hopefully all the way up to 100%.  Pretty graphs showing that I’m making progress!

So I set up this nice system.  I then started writing unit tests against some sections of code.  I then logged bugs in a bug tracking tool, and the developers fixed or explained away most of those issues.  Great!  Everything was fine.  Until…

Developer Disappointing Darrell (names changed) checked in some changes that broke the build.  Although I had emailed out the team links to their project’s builds in Jenkins, they did not monitor them (and due to the IT infrastructure and security concerns… which were unfounded… I could not setup Jenkins to send out email alerts on broken builds).  Disappointing Darrell made sure the code compiled on his machine, but then did not add all the files to Subversion.  So he never knew he actually checked in something that would not compile.

Nanny

Something to this effect would happen about once or twice a week.  I started calling myself the ‘build nanny’.  If the build broke due to a check-in (and I would generally notice within minutes – I actually hacked a way for Jenkins to display a popup on my screen when the build broke), I would find the developer and notify them of the problem.

The problem got worse – there were some developers, Ignoring Ivan, who did not fix any of the issues I found.  So when Jenkins failed, I was not sure if a new unit test failed or if it was one of the existing tests that failed (since it was already broken to begin with).  The environment was one in that my work as a unit tester was not valued very highly (I was a checkbox for one of the requirements in the program).

After talking to some of the leads on the program, my focus shifted from unit testing to creating some valuable tools for the test team.  I then started a higher level system testing using Docker containers before I got fed up of my tests not getting used.  I got to the point of not seeing the point of doing anything at work, because none of my tests were going to be used.

Which leads me to two points…

  1. Developers should write their own unit tests.
  2. Quality is everyone’s responsibility.

Developers Should Write Their Own Unit Tests

As a developer, testing should not catch obvious errors in your code.  Compile errors or issues that can easily be caught by unit tests should be your responsibility.  If you have a tester that loads your code onto a system (or worse yet, multiple systems), and it segfaults and won’t come up…. that wastes a lot of that person’s time.  Frustrated Fred will now have to downgrade a lot of systems due to an oversight that should have been caught before it got to him.  Writing your own unit tests can be similar to double-entry bookkeeping as an accountant or washing your hands as a doctor.

Hand Soap

Unit tests is your line of defense against making stupid mistakes.  I have seen multiple times where a well-written unit test saved me hours of debug time.  Don’t let silly issues get caught by a tester who is going to waste a lot of time undoing your mistake.

I have read there are some places now that don’t have dedicated testers.  The software developers are also responsible for testing.  This makes writing unit tests even more valuable.  Don’t waste time manually testing something over and over that can be automated.  And help prevent yourself from being stupid.  I’ve always considered myself a decent programmer, but I’m a lot better due to writing unit tests against my code.  This goes along the lines of quality being everyone’s responsibility.

Quality Is Everyone’s Responsibility

Ok, not EVERYONE’S… but a lot more people than you realize.

  • Developer – you wrote the code.  Do code reviews, unit testing, continuous integration, and other good software practices that will make you faster and deliver higher-quality software.
  • Tester – generally the last line of defense before the customer sees the product.  But it is NOT their job alone to verify the code is good.  Generally at this level, testers are only verifying functionality, not code structure.
  • Managers – must understand that sometimes code needs to be cleaned up.  This doesn’t directly tie into generating revenue as much as finishing a feature does, but good quality code makes future features faster to develop.  Good quality code = asset.  Bad quality code = liability.  One makes you faster, while the other slows you down (see technical debt).

There are several other positions I could put on there, but you get the picture.  One developer cannot be the ‘hero’ either… if there are several developers producing bad quality code, one developer is not going to magically fix all the other code that is not unit tested/developed with high quality.

Conclusion

  • Write your own unit tests.
  • Work on creating a developer/managerial/company culture built around producing high-quality code.

Best of luck!

Leave a Reply

Your email address will not be published. Required fields are marked *