Agile testing methods embrace the principles of Agile software development which involves all the cross functional Agile team members, in which team members with testing expertise are also involved. This ensures that business value is delivered to the customer at frequent intervals, working at a sustainable pace. There are various testing methods which include writing test cases and running them before writing the code. Some testing methodologies which are commonly used in Agile teams are listed below:

• Test Driven Development (TDD)
• Acceptance Test Driven Development
• Behavior Driven Development (BDD)

There are 3 methods called Test Driven Development, Acceptance Test driven development and Behavior Driven Development which Agile team use to test the code across various levels. Each technique has its own pros and cons and the tests are well written before the code is built.

What is Test-Driven Development?

Test-driven development (TDD) is an advanced technique of using automated unit tests to drive the design of software and force decoupling of dependencies. The result of using this practice is a comprehensive suite of unit tests that can be run at any time to provide feedback that the software is still working. This technique is heavily emphasized by those using Agile development methodologies. Creating and running automated tests inside.

• Abstracting dependencies in an object-oriented world
• Refactoring new and old features to remove duplication in code
• How to Author a Unit Test
• How to Organize Tests into Test Lists
• How to Run Selected Tests

The motto of test-driven development is “Red, Green and Refactor.”

• Red: Create a test and make it fail.
• Green: Make the test pass by any means necessary.
• Refactor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.

The Red/Green/Refactor cycle is repeated very quickly for each new unit of code

Benefits of Test Driven Development

• The suite of unit tests provides constant feedback that each component is still working.
• The unit tests act as documentation that cannot go out-of-date, unlike separate documentation, which can and frequently does.
• When the test passes and the production code is refactored to remove duplication, it is clear that the code is finished, and the developer can move on to a new test.
• Test-driven development forces critical analysis and design because the developer cannot create the production code without truly understanding what the desired result should be and how to test it.
• The software tends to be better designed, that is, loosely coupled and easily maintainable, because the developer is free to make design decisions and refactor at any time with confidence that the software is still working. This confidence is gained by running the tests. The need for a design pattern may emerge, and the code can be changed at that time.
• The test suite acts as a regression safety net on bugs: If a bug is found, the developer should create a test to reveal the bug and then modify the production code so that the bug goes away and all other tests still pass. On each successive test run, all previous bug fixes are verified.

An example of Test Driven Development process is explained below using the Visual Studio.

When Visual Studio Team System is used, the following steps can be performed while processing a work item that is already assigned. Make sure that a Test Project in the solution available for creating new tests. This project should reference the class library in which you intend to add new functionality.

Follow these below steps

1. Understand the requirements of the story, work item, or feature that is being worked on.
2. Red: Create a test and make it fail.
   1. Imagine how the new code should be called and write the test as if the code already existed. We may not get IntelliSense because the new method does not yet exist.
   2. Create the new production code stub. Write just enough code so that it compiles.
   3. Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
3. Green: Make the test pass by any means necessary.
   1. Write the production code to make the test pass. Keep it simple.
   2. Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.
   3. If the code is written so that the test passes as intended, you are finished. Code need not be written more speculatively. The test is the objective definition of “done.” If new functionality is still needed, then another test is needed. Make this one test pass and continue.
   4. When the test passes, it might want to run all tests up to this point to build confidence that everything else is still working.
4. Refactor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
   1. Remove duplication caused by the addition of the new functionality.
   2. Make design changes to improve the overall solution.
   3. After each refactoring, rerun all the tests to ensure that they all still pass.
5. Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/Refactor cycles.

What is Acceptance Test-Driven Development?

Acceptance tests are from the user’s point of view – the external view of the system. They examine externally visible effects, such as specifying the correct output of a system given a particular input. In general, they are implementation independent, although automation of them may not be. (See User story Template in Agile).  Acceptance tests are a part of an overall testing strategy. Acceptance test-driven development is explained in detail on this site.

Acceptance tests are created when the requirements are analyzed and prior to coding. Failing tests provide quick feedback that the requirements are not being met. The tests are specified in business domain terms. The terms then form a ubiquitous language that is shared between the customers, developers, and testers. Tests and requirements are interrelated.

A requirement that lacks a test may not be implemented properly. A test that does not refer to a requirement is an unneeded test. An acceptance test that is developed after implementation begins represents a new requirement. Acceptance criteria are a description of what would be checked by a test.

Given a requirement such as “As a user, I want to check out a book from the library”, an acceptance criterion might be “Verify the book is marked as checked out.” An acceptance test for this requirement gives the details so that the test can be run with the same effect each time.

What is Behavior-Driven development?

• The suite of unit tests provides constant feedback that each component is still working.
• The unit tests act as documentation that cannot go out-of-date, unlike separate documentation, which can and frequently does.
• When the test passes and the production code is refactored to remove duplication, it is clear that the code is finished, and the developer can move on to a new test.
• Test-driven development forces critical analysis and design because the developer cannot create the production code without truly understanding what the desired result should be and how to test it.
• The software tends to be better designed, that is, loosely coupled and easily maintainable, because the developer is free to make design decisions and refactor at any time with confidence that the software is still working. This confidence is gained by running the tests. The need for a design pattern may emerge, and the code can be changed at that time.
• The test suite acts as a regression safety net on bugs: If a bug is found, the developer should create a test to reveal the bug and then modify the production code so that the bug goes away and all other tests still pass. On each successive test run, all previous bug fixes are verified.
• It also reduces debugging time.

Other popular articles:

• What are Project Work Products in Agile testing?
• What is Acceptance Test-Driven Development in Agile Methodology?
• What is Unit testing?
• What is Test harness/ Unit test framework tools in software testing?
• What are Test execution tools in software testing?