The quality assurance (QA) activities in software development generally include: defect tracking, Unit Testing, source-code tracing, technical reviews, integration testing, and system testing. Out of these activities: Unit Testing, source-code tracing, and integration testing are informally left to the developer. Out of these three developer specific activities, Unit Testing seems to be the most overlooked and misunderstood activity with the greatest potential for improving the development process (improving quality, efficiency, etc…).
The procedure [for Unit Testing] is to write test cases for all functions and methods so that whenever a change causes a regression, it can be quickly identified and fixed. – Wikipedia: Unit_testing
By writing good unit tests and employing a good Unit Testing framework you can significantly improve your software development cycle. By writing unit tests you decrease your dependency on a debugger, decrease source-code tracing (debugger walkthroughs), and so on. And by employing a good Unit Testing framework you can begin to lay the scaffolding for other forms of developer specific testing (integration, system testing, and even GUI testing). Unit Testing also contributes to better documentation – if a developer doesn’t understand the purpose of a component they can now read an additional piece of documentation, the unit tests. Unit Testing and Unit Testing frameworks can bring a team of developers to the same level – the capabilities within a team vary by developer. By using the same underlying framework, by identifying general areas that always need Unit Testing we develop a heuristic approach to testing and with that, test patterns, and a new vocabulary to assist with inter developer communication – design patterns accomplish a similar goal. Marc Clifton has a tutorial on Unit Test Patterns.
Unit Testing has its flaws just like any other technique or methodology – there are no silver bullets. Unit Testing is contingent on GOOD unit tests – it’s just as easy to write bad code that works, as it is to write bad unit tests that pass (work). Unit Testing won’t catch every error, but that’s the reality of writing programs, it’s also why we have a large number of software testing (QA) activities – writing software that is 100% bug free is impossible. These are just a couple issues with Unit Testing.
[Test-Driven Development is] a computer programming technique that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test. The goal of test-driven development is to achieve rapid feedback. – Wikipedia: Test-Driven Development
The Test-Driven Development (TDD) programming technique is fundamental to many of the Agile methodologies – particularly the Extreme Programming (XP) methodology. The TDD approach uses Unit Testing as a process for designing and testing software. The core idea behind TDD is to have the developer “write the test first” then write the code to pass the test. The technique forces the developer to “thinking before acting” which is really a “best practice” advisable for everyone – I would hope that “thinking before acting” is practiced informally by most experienced developers, but that’s often not the reality. Other programming techniques that revolve around the “thinking before acting” idea include: the Pseudocode Programming Process (PPP), and the Program Design Language (PDL) Both the PPP and the PDL have gained exposure through Steve McConnell’s book Code Complete.
The mature unit testing frameworks that have gained popularity through the TDD / XP community are important; unit testing through these frameworks will compliment any quality assurance plan and improve any development process.
For more information on Unit Testing and TDD see the following: