Unit Test Methodologies
In the last couple of newsletters I have been talking about Unit Testing. Unit Testing is a technique used by software develoeprs to test the code they are writing to solve a software requirement. The tests are written to exercise the code modules directly, not through an external interface.
Today I wanted to gloss over three general Unit Test Methodologies:
- Test After Development – TAD
- Test First Development – TFD
- Test Driven Development – TDD
Each of these methodologies have commonalities. Before writing code, business requirements are established. A general architecture is established. The different approaches begin to vary at that point.
Test After Development is essentially that. Code is written; tests are written at a later time. Sometimes the tests are written immediately after the code, verified, and then the development moves on. This technique generally has good code coverage.
Sometimes tests are written after bugs are reported, or where the code is more complicated. Due to this practice, the percentage of code coverage by tests is often rather small. This practice pushes the identification of issues farther down the development lifecycle. Studies have shown that the cost of fixing a bug grows dramatically each layer it extends from the developer. QA discovered bugs cost more than Developer discovered bugs. System testing bugs even more. Production bugs are considerably more expensive.
Test First Development is the opposite of Test After Development. In this scenario, tests are written before code. Once the code passes the tests, then the code is considered complete. The tests should reflect the business rule requirements. Passing all of the tests is a demonstration that the software meets the business requirements. You now have an automated mechanism to confirm your business rules in an ongoing basis.
The biggest difference in this approach is that there is no need to maintain a document of business rules for code to be written. Instead, you have documented your business rules as something that may be validated over and over, without additional efforts by others. Your tests fully reflect your business requirements.
In order to do Test First Development there may be a fairly detailed design up front regarding what classes, methods, etc. are to be developed so that tests may be designed that are useful. From the design an iterative approach is often used. A test is written, and then the software is written to implement the test requirement.
Test Driven Development – TDD looks a lot like TFT. The difference is that there is little up front design work establishing how the final software will be architected. In the case of TDD, all that is known when development begins are the business requirements.
First a test is derived from the requirements.
Second, code is written fulfilling the test.
Third, the next test is written to take the next step in fulfilling the business requirements.
Rinse and repeat.
This process doesn’t mean that you don’t have a plan in mind when coding begins; otherwise, how would you decide what the first test is to write? What it means is that you are using tests and code to flesh out your software design rather than a software design tool such as UML. The design emerges, just as it does when you are using a design tool, except that you design is documented in the form of tests and working software instead of a diagram.
Some argue that there would be a lot of time lost when you find you have gone down a wrong path. That is true. Think how many times you have taken time to put together a complete class diagram and it required modification, along with all the code written to that point, because of some situation you didn’t take into account. It is much harder when all you have is software design diagrams, and a developer discovers a flaw in the design after the project is 60% complete. Without unit tests, major refactoring at this point is lost to the schedule constraints.
This is the key reason the tests work in your favor. When you determine a need to change the pattern you are using, because you have tests in place refactoring your code is an easier task. You have the confidence to make changes, sometimes radical changes, because you have the unit tests to fall back on where the software isn’t changing.
Unit tests don’t reduce the value of software documentation. Often a good set of UML diagrams make it easier for new developers to jump into the code. TDD, on the other hand changes the order in which your UML might be generated. Instead of using UML to stub out your code, the code may be used to generate the UML diagrams.
Alex writes:
I have mixed feelings on unit testing. When done correctly, I can be an invaluable tool. However, when done badly it can be a waste of time and effort.
I’m sure you have seen code delivered that couldn’t possibly been unit tested. This is as true for old style development as in agile development.
I worked on team responsible for building and deploying software developed using agile methods and test driven development. However, the unit tests were little more that test stubs. Therefore, even though all the unit tests were executed successfully the code never worked first time.
However, to you assure that the unit tests are of value? Who should be responsible reviewing the unit test or should a developer in a test driven development project write their own unit test at all?
As an aside, I’m starting to hear complaints about agile development projects. Mainly, it has to do with maintainability of the software and a lack of proper documentation of what the application does. With 2 to 4 week development cycles how are key functional area documented so that non development teams can understand how the application is put together and how it should work. I’ve not worked on a agile project but my understanding is that it is light on documentation.
Share your thoughts or experiences with unit testing by sending me an email at btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Script
dba3_ddl_CalendarSchema_Article
Modeling Date Logic III: Implementing Business Calendars (by example in MS Sql Server 2000) http://bitonthewire.wpengine.com/see/17379 Se… (read more)