You are on page 1of 6

What are the different Agile Testing

Methodology? Test Driven Development,


Behavior Driven Development
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.
2

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.

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 users 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.

You might also like