View Christos Tranoris's profile on LinkedIn


Visit The Model Driven Software Network

Who's online

There are currently 0 users and 10 guests online.

Recent comments

Syndicate

Syndicate content

Test Driven Development part II : Code coverage

Usually the best result that you can get out of your TDD practice is a 100% code coverage. Code coverage is a software metric that tells how much of your production code is run either when the unit tests or the actual application run and usually consists of several metrics criteria. If 100% of the lines of your production code are run when the unit tests are run, then you have 100% code coverage.

Well, you will see though that during development and after a few thousants lines of code, that hitting a 100% could be really difficult and that's why you will find youself trying writting more unit tests in order to achieve it. Ofcourse, hitting 100% code coverage from my perspective, doesn't mean that your software is bug free, but anyway you have captured many corner case scenarios.

The most difficult part is how to achieve 100% code coverage. Well, usually you do the following: refactor your production and test unit code. Keep always in mind to program/design for testability. Sometimes you must add some extra overhead functions to your classes only for testing. Some times you need extra parameters. Some times you need to return a value from a function even if it is not neccessary. But each time the goal is the same: To enable unit tests everywhere.

Also, don't forget mocking some external objects. Usually a mock object will help you to achieve a 100% code coverage. The mock object for example can actually mock another system and give you any possible responce (even erroneous and corner cases) so that you can really test your system. For example in a client-server app, if you write the client you can mock the server with a simple object that response to any request with many possibilities.

How to examine code coverage? You need a tool. Nowadays every language has a code coverage utility, so google it and use it.

Finally, from my personal experience, I suggest you to run a code coverage utility often against your code. Some developers leave it until the end. Just to check what happens and if they covered everything. I suggest you to introduce it to your TDD practice often. You will find out how often to execute and when you are comfortable with it, but atleast try to execute it every now and then. Maybe it will tell you to change some tactics here or introduce a mock object there.

 

 

Posted in Submitted by tranoris on November 17, 2007 - 22:41.