What is Test Driven Development?
Test-Driven Development (TDD) originally was created as part of the Extreme Programming (XP) methodology, where it was known as ‘Test-First’ concept. The idea is that developers generally write their tests after the code is written and therefore are only testing the functionality as they wrote it, as opposed to testing it to make sure it works the way it was actually intended!
Also, there is a tendency when writing a test after the fact of only writing the code to test the so-called ‘happy path’ – the path that the developer expects the user to take. The usual process follows these steps:
The requirements are defined, from these requirements, the development team creates the design of a specific part of the application, and the developers then write the necessary production code. They will then document the code after the fact and create tests (manual and/or automated) to test that the system works as expected. The testers then run the tests, and any bugs found are then fixed.
This approach means that (a) you are only testing the system based on the code that was already written, and (b) when you change the system to fix one of the identified bugs, there is not an automated way to make sure you have not changed the design or introduced new bugs.
With a test-driven-development approach, the process is somewhat different:
The requirements are used to directly create the acceptance tests (the ones that determine if the system meets the needs of the users / stakeholders as defined by the requirements). The team uses the requirements and acceptance tests to design the system and create the appropriate unit tests. These tests are now executed, and (since nothing yet exists) will naturally fail. However the unit tests are now the detailed definition of the requirements.
The team then writes the production code so that the tests now pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it. At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality. This refactoring process is a key attribute of agile development methods such as XP and Scrum.
One final aspect is that whenever a bug is found, that implies that the unit test coverage of the system is not sufficient, and before fixing the bug, the unit tests should be extended to reproduce the bug as a test failure. Only once this has been done, should the bug be fixed (causing the new test to pass). This ensures that any old bugs are not inadvertently reopened in the future.
What Makes SpiraTeam the Best Choice for TDD Projects
When your company requires better software planning tools, there are a lot of choices in the marketplace. However, if you want the best in agile software development with there is only one solution.
SpiraTeam® is a complete software project management system in one package, that manages your project's requirements, releases, iterations, test cases, tasks and bugs/issues. Designed specifically to support agile methodologies such as TDD, Scrum, Extreme Programming (XP), DSDM and Agile Unified Process (AUP) it allows teams to manage all their information in one environment.
| SpiraTeam | Extreme Programming | Scrum | DSDM |
| Epic | Epic | Epic | Feature Group |
| Requirement | User Story | Backlog Item | Requirement |
| Task | Task | Task | Task |
| Release | Release | Release | Release |
| Sprint | Iteration | Sprint | Iteration |
| Test Case | Acceptance Test | Acceptance Test | Test |
Integrating Unit Test Frameworks
With its integrated quality assurance and test management functionality, you can integrate your xUnit unit tests with SpiraTeam to have the complete picture in one system.
When you add on our Rapise test automation platform you can write automated acceptance tests during the requirements definition process and automate them once you have an initial prototype in place.
SpiraTeam® provides reporting dashboards of key project quality and progress indicators - requirements test coverage, task progress, project velocity, as well as top risk and issues – in one consolidated view that is tailor-made for agile software development methodologies as well as supporting your legacy/hybrid waterfall projects. The top reasons that our customers choose SpiraTeam® over other solutions are:
- It is a complete solution that includes requirements management, release planning, iteration planning, task estimation and defect tracking all fully integrated from day one.
- Highly intuitive web application that provides a complete picture of a project’s status and health yet requires only a web-browser.
- Methodology Agnostic – SpiraTeam® can be used equally web for any agile software development methodology – including Scrum, AUP, XP, DSDM
- Ability to leverage your existing technology investments. SpiraTeam® integrates with many third-party defect-management systems and software configuration management (SCM) systems.
In addition, we provide superb technical support that ensures that enquiries and questions are dealt with in a timely and professional manner.
How do I Get Started?
To learn more about SpiraTeam and how it can improve your agile software development processes please: