Again I'm amazed at the confidence that adding some unit tests to code gives me. I've spent the day adding unit tests to some code that I threw together as a quick proof of concept, and that's triggered a set of refactorings that have turned the code into a production quality assembly that's ready to go live.
My next task is a test spec for a website, which should be an interesting chance to try to demonstrate how I think they should be written. I don't agree with the way that the test team do things here, and so I want to prove that you can do full testing at each stage without costing too much more. There's a certain amount of reluctance to do comprehensive testing here and there's an idea that validating requirements is enough. While this is technically true for the projects in question it leads to problems down the line as code changes, or conditions not considered by the requirements occur. These projects are all embedded, so the inputs are all very controlled and there's no pesky user trying to break things.
The key to writting solid software is trusting nobody. Whenever you receive data, be it from the serial port or as a parameter to a function you should check that it seems valid. It's a bit more complicated on embedded projects because processor time and memory is limited, but the hardware we're using can take it.
All I need to do now is find an answer to the question as to if more quality will cost more than the time spent finding and correcting problems.
What other blogs are saying about this post.
3:19:07 PM 
|
