Devlico.Us
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @devlicious

Derik Whittaker

Thoughts on Software Development, .Net, OOP, Design Patterns and all things cool



Thoughts on writing quality test code vs writing quality application code

Anyone that is a practitioner of testing or specially TDD knows that the quality of your tests are a direct measure in the assumed quality of your tested code.  Better put, if your tests suck, you can assume very low quality from your code.

So what is harder, writing quality code or writing quality tests?  My vote is that writing quality test code is harder then writing quality application code.

When it comes to writing 'quality application code' the measure of quality is really in the eye of the developer.  What one person calls good code may be called crap by another developer.  But as long as the code meets the business needs, it should be at least considered quality (if not simply functional) code. 

However, creating quality test code is a little more measurable.  One possible way to measure this is by code coverage (please do not take that statement as high code coverage equals high quality as this is NOT the case).  Another is to simple make sure the tests exercises as many different business scenarios as practical (notice here I did not say possible because at some point you reach the point of diminishing returns and should just stop).  Finally, if you keep your tests compact and focused you should be able to create quality tests.

To me the real measure of quality test code is how maintainable is it?  Is it very painful to refactor when the code under test needs to change?  If you can maintain your test code with very little friction or effort, they I would say chances are high you have high quality test code.

Hints your test code may be poor quality.

  • Test code does not test the intent of the code
  • Test code becomes to brittle to maintain going forward
  • Test code is heavy (those testing multiple things)
  • You dread making changes to your code base for fear of having to modify your test code.

Hints your test code may be of high (er) quality

  • Causes very little friction during future code changes
  • Test code is light weight, tests only a single concept
  • You do not dread making changes to your code base for fear of having to modify your test code.

So, what do you think?  Which is harder and why?

Till next time,



Comments

Grant Palin said:

Interesting question.  I have recently been figuring out the unit testing concept, and working some tests into one of my ongoing projects.  I would say the test code I have is somewhat on both sides of it, with some aspects of each.  But it is a work in progress.

Having thought about it, I can appreciate that your production code could be great, but development process can be bogged down if your tests code is lousy.

# May 21, 2008 2:23 PM

Reflective Perspective - Chris Alcock » The Morning Brew #99 said:

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #99

# May 22, 2008 3:20 AM

Derik Whittaker said:

While putting together one of my last posts one thought kept scrolling through my head.  This was

# May 23, 2008 10:58 AM

The Inquisitive Coder » Blog Archive » Weekly Links 5 said:

Pingback from  The Inquisitive Coder  » Blog Archive   » Weekly Links 5

# May 24, 2008 3:30 AM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Derik Whittaker

Derik is a .Net Developer/Architect specializing in WinForms working out the northern suburbs of Chicago. He is also believer and advocate for Agile development including SCRUM, TDD, CI, etc.

When Derik is not writing code he can be found spending time with his wife and young son, climbing on his bouldering wall, watching sports (mostly baseball), and generally vegging out. Check out Devlicio.us!

Our Sponsors

Proudly Partnered With


This Blog

Syndication

News