Test Driven Development (TDD)

In layman's terms, Test Driven Development (TDD) is a software development practice that focuses on creating unit test cases before developing the actual code. It is an iterative approach combining programming, unit test creation, and refactoring.

Test-driven development is a methodology that implies writing unit tests before writing production code. In other words, first, you write tests for a non-existing code, then you write the needed code, and then the test passes. How does this approach fit into XP (extreme programming) concept? Simple: let’s take code testing to an extreme and write tests before there is even any code written. A shoutout to Kent Beck here — the father of extreme programming and one of the 17 original signatories of the Agile Manifesto.

Now, the next question is how does TDD fit into the agile concept? The answer is actually quite simple. One of the main features of agile is the need for regular feedback since project requirements may change throughout the development process and developers need to adapt to the changes. Regular feedbacks help maintain transparency and quickly identify the source of an issue before the code goes anywhere further than the developer’s laptop.

The simple concept of TDD is to write and correct the failed tests before writing new code (before development). This helps to avoid duplication of code as we write a small amount of code at a time in order to pass tests. (Tests are nothing but requirement conditions that we need to test to fulfill them).

This type of development is a process of developing and running automated test before actual development of the application. Hence, TDD sometimes also called as Test First Development.

TDD Cycle

Writing the tests first: The tests should be written before the functionality that is to be tested. This has been claimed to have many benefits. It helps ensure that the application is written for testability, as the developers must consider how to test the application from the outset rather than adding it later. It also ensures that tests for every feature gets written. Additionally, writing the tests first leads to a deeper and earlier understanding of the product requirements, ensures the effectiveness of the test code, and maintains a continual focus on software quality. When writing feature-first code, there is a tendency by developers and organizations to push the developer on to the next feature, even neglecting testing entirely. The first TDD test might not even compile at first, because the classes and methods it requires may not yet exist. Nevertheless, that first test functions as the beginning of an executable specification.

Each test case fails initially: This ensures that the test really works and can catch an error. Once this is shown, the underlying functionality can be implemented. This has led to the "test-driven development mantra", which is "red/green/refactor", where red means fail and green means pass. Test-driven development constantly repeats the steps of adding test cases that fail, passing them, and refactoring. Receiving the expected test results at each stage reinforces the developer's mental model of the code, boosts confidence and increases productivity.

What is acceptance TDD and Developer TDD

1. Acceptance TDD (ATDD): With ATDD you write a single acceptance test. This test fulfills the requirement of the specification or satisfies the behavior of the system. After that write just enough production/functionality code to fulfill that acceptance test. Acceptance test focuses on the overall behavior of the system. ATDD also was known as Behavioral Driven Development (BDD).
2. Developer TDD: With Developer TDD you write single developer test i.e. unit test and then just enough production code to fulfill that test. The unit test focuses on every small functionality of the system. Developer TDD is simply called as TDD.The main goal of ATDD and TDD is to specify detailed, executable requirements for your solution on a just in time (JIT) basis. JIT means taking only those requirements in consideration that are needed in the system. So increase efficiency.

Test structure

Effective layout of a test case ensures all required actions are completed, improves the readability of the test case, and smooths the flow of execution. Consistent structure helps in building a self-documenting test case.

1. Setup: Put the Unit Under Test (UUT) or the overall test system in the state needed to run the test.
2. Execution: Trigger/drive the UUT to perform the target behavior and capture all output, such as return values and output parameters. This step is usually very simple.
3. Validation: Ensure the results of the test are correct. These results may include explicit outputs captured during execution or state changes in the UUT.
4. Cleanup: Restore the UUT or the overall test system to the pre-test state. This restoration permits another test to execute immediately after this one. In some cases, in order to preserve the information for possible test failure analysis, the cleanup should be starting the test just before the test's setup run.

Individual best practices

Some best practices that an individual could follow would be to separate common set-up and tear-down logic into test support services utilized by the appropriate test cases, to keep each test oracle focused on only the results necessary to validate its test, and to design time-related tests to allow tolerance for execution in non-real time operating systems. The common practice of allowing a 5-10 percent margin for late execution reduces the potential number of false negatives in test execution. It is also suggested to treat test code with the same respect as production code. Test code must work correctly for both positive and negative cases, last a long time, and be readable and maintainable. Teams can get together and review tests and test practices to share effective techniques and catch bad habits.

a unit is most commonly defined as a class, or a group of related functions often called a module. Keeping units relatively small is claimed to provide critical benefits, including:

• Reduced debugging effort – When test failures are detected, having smaller units aids in tracking down errors.
• Self-documenting tests – Small test cases are easier to read and to understand.

Advanced practices of TDD can lead to acceptance test–driven development (ATDD) and specification by example where the criteria specified by the customer are automated into acceptance tests, which then drive the traditional unit test-driven development (UTDD) process. This process ensures the customer has an automated mechanism to decide whether the software meets their requirements. With ATDD, the development team now has a specific target to satisfy – the acceptance tests – which keeps them continuously focused on what the customer really wants from each user story.

Anti-patterns

• you should always start a unit test from a known and pre-configured state
• Dependencies between test cases. A test suite where test cases are dependent upon each other is brittle and complex. Execution order should not be presumed. Basic refactoring of the initial test cases or structure of the UUT causes a spiral of increasingly pervasive impacts in associated tests.
• Interdependent tests. Interdependent tests can cause cascading false negatives. A failure in an early test case breaks a later test case even if no actual fault exists in the UUT, increasing defect analysis and debug efforts.
• Testing precise execution, behavior, timing or performance.
• Building "all-knowing oracles". An oracle that inspects more than necessary is more expensive and brittle over time. This very common error is dangerous because it causes a subtle but pervasive time sink across the complex project.
• Testing implementation details.
• Slow running tests.

TDD Vs. Traditional Testing

Below is the main difference between Test driven development and traditional testing:

• TDD approach is primarily a specification technique. It ensures that your source code is thoroughly tested at confirmatory level.
• With traditional testing, a successful test finds one or more defects. It is same as TDD. When a test fails, you have made progress because you know that you need to resolve the problem.
• TDD ensures that your system actually meets requirements defined for it. It helps to build your confidence about your system.
• In TDD more focus is on production code that verifies whether testing will work properly. In traditional testing, more focus is on test case design. Whether the test will show the proper/improper execution of the application in order to fulfill requirements.
• In TDD, you achieve 100% coverage test. Every single line of code is tested, unlike traditional testing.
• The combination of both traditional testing and TDD leads to the importance of testing the system rather than perfection of the system.
• In Agile Modeling (AM), you should “test with a purpose”. You should know why you are testing something and what level its need to be tested.

TDD Frameworks

• Junit
• TestingNg
• csUnit and NUnit
• Rspec

Advantages of TDD

• Early bug notification
• Better Designed, cleaner and more extensible code.
• Confidence to Refactor
• Better code quality
• Testing and debugging are built into the process
• Better project documentation
• Better productivity
• High test coverage
• Quality assurance is less expensive