Examples of Unit Testing/Test Driven Development in real life

[FabiolaDelaCueva]

Writing code that is testable requires a change in how the developer approaches a programming task. It does not come natural for people who are used to writing code fast that gets things done and gives the results we expect right away. Another mental block is not knowing where to define the Unit. In this Unit Testing Group the book "The Art of Unit Testing" has been recommended before: http://artofunittesting.com/

In his book, Roy Osherove defines the Unit more as a unit of work. Here is Roy's definition:

"An automated piece of code that invokes the unit of work being tested, and then checks some assumptions about a single end result of that unit. A unit test is almost always written using a unit testing framework. It can be written easily and runs quickly. It’s trust-worthy, readable, and maintainable. It is consistent in its results as long as production code has not changed"

This document is here to add different examples of using Unit Testing/Test Driven Development in real life. So we can help each other make that mental change on how we approach software development and get to Test Driven Development.

Let's start by adding James McNally excellent blog post sharing how he fixed a bug recently and he used Unit Test Framework to not only test that the bug was fixed but also to document what were the values that he used to test his VI:

http://www.wiresmithtech.com/fixing-a-simple-bug-with-test-driven-development/

Feel free to add more links to this document so we can all continue to improve our Test Driven Development skills.

[James_McN]

I love it when one phrase can change your thinking,

In his book, Roy Osherove defines the Unit more as a unit of work

I've not quite put my finger on this as nicely before but this is a great mentality. Don't worry about testing units of code, rather units of work.

This frames nicely with the idea that 100% code coverage is largely a waste of time (80% is often more considered) but 100% of feature coverage seems like a good target.

[tyk007]

What's also interesting is that this line of thinking is a recent change from Roy's previous concept of a unit (more traditionally a method). I have the current and previous revision of his book where he expresses both mentalities but the key motivator for me in the latest line of reasoning is to reduce the scope of unit testing to the factors that are key for a solution to work rather than the individual pieces. This reduces the burden of change to unit tests when refactoring solutions - although refactoring LabVIEW solutions tends to be more work than C# as described in Roy's book.