AWB - 12 - Agile Testing

405 Agile White Book – AXA Emerging Markets EMEA-LATAM
Chapter 12
AGILE TESTING
V1.0

Contents
WHAT I WILL LEARN IN THIS CHAPTER?.................................................................................................................................................................... 408
WHY TESTING.................................................................................................................................................................................................. 409
TEST DRIVEN DEVELOPMENT.................................................................................................................................................412
TESTING APPROACH IN AGILE ................................................................................................................................................415
TYPES OF TESTS ............................................................................................................................................................................................... 416
UNIT TESTS ........................................................................................................................................................................416
INTEGRATION TESTS.............................................................................................................................................................416
FUNCTIONAL TESTS..............................................................................................................................................................417
ACCEPTANCE TESTS .............................................................................................................................................................418
WHERE TO START ............................................................................................................................................................................................ 419
TEST FIRST APPROACH ..........................................................................................................................................................419
WRITE GOOD UNIT TESTS .....................................................................................................................................................421
HOW TO WRITE GREAT TESTS............................................................................................................................................................................ 422
WHAT TO CHECK .................................................................................................................................................................423
TYPICAL TEST STRUCTURE.....................................................................................................................................................424
UNIT TESTS REFACTORING.....................................................................................................................................................425
TESTING TECHNIQUES....................................................................................................................................................................................... 426
TEST CODE THAT INTERACTS WITH DATABASES..........................................................................................................................426
TESTS AND INTERACTIONS BETWEEN MODULES.........................................................................................................................427
CONTINUOUS INTEGRATION ..................................................................................................................................................428
DANGERS OF INVERTING THE SEQUENCE.......................................................................................................................429
TAKE AWAY.................................................................................................................................................................................................. 430

Agile Testing
Agile testing uses a group of programming
techniques that require you to write an automated
test before the actual code and benefits from all the
framework principles and practises, such as cross-
functional Teams, Quality, Prioritisation, Business
Value, etc. This guarantees quality and flexibility
while keeping the focus on people’s interactions.

What I will learn in this chapter?
AGILE TESTING
KNOW HOW TO
- Different types of tests.
- Design, architect & code
at the same time
- 1st
Write a test
- 2nd
Write implementation
- 3rd
Test and pass it
LEARN ABOUT
IMPROVEMENT
TECHNIQUES
- Refactoring
- Continuous integration
- Continuous deployment
I know the benefits of using test-driven development.
I know how to write a good test & its backbones.
I know how the benefits of continuous integration.
BENEFITS OF
AGILE TESTING

WHY testing
Agile testing is aligned with all the Agile principals (quality, simplicity, working at a sustainable
pace, cross-functional Teams, etc.), while placing a special focus on the expertise contributed
by testers, to ensure delivering high Business Value at frequent intervals. It is not a
separate phase but an integral part of software development along with coding and designing.
Her team members with Testing backgrounds give their expertise in producing examples of a
desired behaviour by understanding a specific User Story (requirement) and gathering
feedback from the Product Owner.

WHY testing
These guidelines are turned into Unit Tests that exercise implementation to support the
process of creating a high-quality product. This process gives programmers the confidence to
make changes to the product as they know that tests will tell them if they have some broken
functionality.
The technique helps the company take their costs down and consolidate a solid product.

WHY testing
Different kind of tests can also be automated and run every time a change is made in the
codebase, making the total cost lower and helping align everyone’s expectations with the
software produced.
We find testing and automation as one of the most effective feedback mechanisms that Agile
Teams have for guaranteeing stable and high quality products.

WHY testing
TEST DRIVEN DEVELOPMENT
Test-driven development (TDD) is an advanced unit test practice in which test is written
before the code. This makes TDD more of a designing practice than a testing one. It is applicable
for both unit test and integration test. Test-driven development includes the following benefits:
 TDD promotes understanding the requirements before development starts, knowing
which "contract" must meet the code.
 Combined with Refactoring and with iterative and gradual design, TDD serves as support to
the concept of emerging architecture.
 As a result,
 The design and code are simple and "clean", and it is only written what is
necessary in order to meet the compliance of functioning requirements / specification
of the method / component, avoiding over-engineering.
 The code is testable from the start.
 TDD is also test automation. The first thing done is translation of requirements to
test (when passing tests, it will ensure that the software meets the requirements that
have been established) thus, per system, automated test code is provided.
The easiest way is to refer the following steps for following TDD practice:
1. Write the unit test that ensures the correct running of the
functionality to be developed and check whether the test
fails.
2. Write the code that makes the test pass successfully.
3. Refactor the code written to eliminate duplication and make
improvements.
4. Return to ensure the test passes and the code still works.

WHY testing
Because most of the TDD tools use a green and red signal when test work/doesn’t work, we refer
this sequence as Red-Green-Refactor.
Picture is taken from http://www.thealmightyjenny.com/
It is important to remark that the aim of TDD is not just to validate what is done but –more
importantly- to clarify what is needed in order to create clear, flexible and stable code.
For more information about TDD, check out Chapter 11 - Extreme Programming.

WHY testing
As we mentioned before, a Unit Test is a function which verifies that a method or group honours
its contract or, what in other words, the implementation under a test meets the desired
requirements. This approach fully assumes that developers have all the information needed to test
all the possible pathways. This includes not only correct inputs, but also incorrect inputs, so
that error handlers can be verified as well.
This helps developers know:
- How the implementation will handle errors.
- Which tests verify all code pathways.
- That Unit Tests can be used as a documentation guideline by other developers when
adding or modifying code.
The ability to write comprehensive tests is vital information to any person who wants to
implements new code, therefore good Unit Tests should always ensure that all the different
pathways are exercised (code coverage).

WHY testing
TESTING APPROACH IN AGILE
Normally during the product development there are a lot of people with different views, needs and
roles, and depending on this, different tests might need to be used; this includes but not limited
to:
Acceptance Tests – They focus on making sure that they can handle or resolve what the
client asked for. The main actor here is the Tester with close collaboration from the rest of
people and the Customer (or Product Owner if using Scrum).
Integration Tests – In this level, test process focuses on combining individual software
units/components as a group (i.e. different modules that are part of one product). The
purpose here is to expose faults in the interaction between the integrated units.
Unit Tests – Short program fragments written by developers that exercise some narrow
part of the product's source code and check their results.
Regardless of the type of test being used, everything is done incrementally and iteratively with
the aim to add value to the Potential Software Increment.
These are some of the advantages I have seen when using tests:
o Developers know whether the last task has been completed successfully as
specified by the associated tests.
o Code can be maintained easier, something which helps make quicker changes.
o Big refactoring activities can be done with higher confidence.
o Teams can make sure they are delivering what the customer asked for, and
with high quality.
o Developers can automate all Tests from the present and past
(regression tests) to assure the system health.

TYPES of tests
UNIT TESTS
A unit test is a test written by the developer to verify that a relatively small piece of code is doing what
it is intended to do. As we have seen, they are narrow in scope, they should be easy to write and
execute, and their effectiveness depends on what the programmer considers to be useful. Unit Tests
are intended for the use of the development team only.
INTEGRATION TESTS
An Integration Test is done to demonstrate that different pieces of the system work together.
Integration Tests cover the whole application, and they require much more effort to be placed together.
They usually need many different resources such as database instances and hardware to be allocated
for them.
Integration Tests generally use similar environment to production and, as a result of that,
complexity gets exponentially higher.

TYPES of tests
FUNCTIONAL TESTS
Many scenarios need to test external components or black-boxes where people won´t be able
to access the implementation, only its behaviour.
This situation is called Functional Testing and is used when someone can just feed inputs and
verify outputs without knowing their internal implementation.
In this case, the person do not usually have information regarding:
- How the box handles errors.
- Whether the inputs are executing all code pathways.
- How to modify the inputs so that all code pathways are executed.
- Any internal dependency or internal resource.
As you can see, functional tests limit the ability to thoroughly test the code, primarily because
the individual doesn´t know if all the code pathways are being tested. Typically, a Functional
Test only verifies that a “good” output is obtained as a result of a known input.
They are generally written by a tester to check that the product behaves as expected or by a
developer to verify that a component returns the expected values.

TYPES of tests
ACCEPTANCE TESTS
An Acceptance Test checks an expected behaviour of a software product expressed in the
Acceptance Criteria part of a User Story. They are meant to satisfy a contractual obligation
between Business and I.T. and are generally written by the Tester using a specific suite.
Similarly to Unit Tests, Acceptance Tests are generally understood to have a clear result, pass or
fail. This determines whether or not the system satisfies its acceptance criteria and enables the
customer to determine whether or not to accept the product. Acceptance Tests check how the
product conducts itself (screen, results, performance, etc.) without knowing the way the piece of
software was implemented (Functional Test).
As a benefit they encourage closer collaboration between Developers on the one hand and users or
domain experts on the other, as they require the business requirements to be expressed in a language
understood by everyone.

WHERE to start
TEST FIRST APPROACH
Test first technique “forces” developers think in a different way, focusing on acquiring a deeper
and earlier understanding of the product instead of doing it while writing the solution. As a
result of that, a continual focus on the product quality is kept while growing the codebase.
As a general rule, code is always written in direct response to a Test. It means that you write the
Test first before adding a single line of code to your implementation.
The first step then is to write the test; it will not initially compile because none of the required
classes or methods exist.
[Test]
public void ShouldReturnOne()
{
string actual = English.NumberToWord (1);
Assert.AreEqual("one", actual, "Expected the result to be "one"");
}
Most of the unit test suites use tags to indicate that this is a “special” function and offer a couple
of methods to check the expected result.
AreEqual - Checks whether two values or references are the same.
IsTrue/IsFalse - Checks whether the outcome is True/False.
IsNull/IsNotNull - Checks whether the outcome is Null/not Null.
IsInstanceOfType -Verifies that the specified object is an instance of the specified
type.

WHERE to start
If the specified condition is false, then the test will fail and the suite will exhibit the specified error
to the developer. Otherwise, the test will be marked as green.
All needed classes and methods should initially be implemented as “empty” boxes in order for the
test to compile.
public static string NumberToWord (int p)
{
throw new Exception("The method or operation is not implemented.");
}
The next step is always to start coding the production implementation until the test passes.
public static string NumberToWord(int number)
{return "one";
}
The simplest code to resolve the original problem should be written and then more tests added
when additional functionality is needed (i.e. ReturnTwo, ReturnOneHundred, etc.).
As you can see, it forces everyone to think through requirements or design before a single line
of functionality is written.

WHERE to start
WRITE GOOD UNIT TESTS
As a rule of thumb, you write just one small test at a time, make it work as quickly as possible
and then write another test. In this way, code and tests increase and establish a solid
foundation for the product.

HOW TO WRITE great tests
I believe the following practises should make your code shine and allow everyone to easily read
and maintain it at any time:
 Make sure the effort or abilities needed to create or modify a test are never greater than
implementing the production code itself.
 Assure only one thing at a time is tested.
 Avoid adding multiple assertions in a single Unit Test.
 Isolate tests from other code in the application as well as any external dependencies or
events by using mock objects (we will see it soon).
 Make sure tests are capable of being run over and over and produce similar
results.
 Never assume that tests are going to be run in any specific order.
 Create tests that are easy to automate.
Remember that you should only write code to 'fix' a failing test. This mean that code should
do just what is required in order to make the test pass and nothing else.

WHAT TO CHECK
We generally find that developers initially struggle to establish what is needed to test. The
following lines can give you some ideas:
Boundary – Define the list of prescribed boundaries conditions you need
for the test (Range, order, existence, etc.)
Cardinality – Have in mind the number of the output elements and values
you expect.
Timeframe – Delimit a Time considered as relevant (i.e. Are results
obtained in the expected time interval?)
Cross-checks – Check the results by using other forms of processing.
Error-force – Think how you can force error conditions to check
boundaries.
Performance – Verify what the minimum performance requirements are.

TYPICAL TEST STRUCTURE
An effective test structure ensures that all required actions are completed. In general, they
are independent from product code -different solution- and offer a consistent structure that allows
you build a self-documenting test. A commonly applied structure has the following four parts:
Setup – Place where the right state to run the test is set.
Exercise – Runs the code to be tested.
Validate – Place that ensures the tests results are correct.
Cleanup – Special area where the overall product is restored to the pre-test
state.
These parts perform all setup and clean-up actions required by the test, this includes creating a
database connection, instantiating some dependant class, initializing state/global variables, etc. It
is not also unusual to have extra setup and clean-up sections at the solution level. The main
reason to require them is mainly based on performance reasons.
We have seen that this is one of the parts that causes more problems when people start using
Unit Tests. This is due to the fact that complex environments normally require elaborated setup
and clean-up stages which in themselves may be buggy, time consuming, and difficult to maintain.

UNIT TESTS REFACTORING
Remember that tests are code that needs to be refactored and improved, in the same way as any
other part of the production code, so XP refactoring techniques can be also used in here.
Sometimes you encounter failing tests even though the change made to the code was completely
fine; this usually means that you have encountered conflicting requirements. This frequently happens
when a new requirement conflicts with an old feature that may no longer be valid. You have two
possible alternatives in here:
Delete the failing test after verifying that it is no longer valid.
Change the old test so you test the new requirement.
Sometimes an old test might need just to include a new initialisation process as a result of a change in
shared objects (i.e. database). If that is the case, you should only need to refactor the setup part to
make sure it uses the new way.
One last thing to have in mind is that duplication in tests code greatly increases the cost of writing
and maintaining them. As a result of this, we recommend you reuse as much as you can as long as it
does not compromise the value of test as documentation.

Here are some ideas that might help:
- Perform most tests without the database (check
the next section).
- Allow each test to prepare their own set of data on
the database and rollback the changes when the
clean up is executed.
- Use in-memory databases (Derby, H2, HSQLDB,
etc.)
TESTING techniques
TEST CODE THAT INTERACTS WITH DATABASES
You may come across code that interacts with databases, and in this case, adjusting your tests to take
this into account is required. A similar scenario is found when Functional Tests that require
preparation are used, for example, the need of a predefined set of values to ensure that tests always
have the same data to work with.

TESTING techniques
TESTS AND INTERACTIONS BETWEEN MODULES
As we have mentioned before, a Unit Test should only verify one method at a time. It means that
some parameters are passed to just one module, and once values are returned, the assertion should
verify that output.
There are many scenarios where modules may use other modules, for example, to get data from a
database, write a file to a folder, etc. This obviously breaks the “test one method” principle and adds
variability to the process.
In order to stick to the rule, the dependency should be substituted with one that is easier to handle
during testing. This technique is known as dependency injection or mock objects and gives
isolation while keeping simplicity.
Basically, the injected dependency pretends to implement the required functionality, replacing it
with one that is easier to control from the test. Another scenario where mock objects are needed is
when good performance or a simplified setup and clean-up process is needed. These are some of
the benefits of “mocking” objects:
- Code can be tested even if the dependency is not available yet.
- Indirect outputs can be captured and controlled.
- Error conditions can be simulated, such as timeouts and connection errors.
- Any type of “hard to set up” dependencies (i.e. low databases or connections) can be avoided.
Have in mind that writing and using substitutes may be long, complicated and susceptible to error and,
in order to prevent this, there are some frameworks available in the market that simplify the whole
process (EasyMock, Mockito, jMock, etc).

TESTING techniques
CONTINUOUS INTEGRATION
Continuous Integration (CI) is a practise coming from Extreme Programming (XP) that uses a tool
which helps developers integrate code and Unit Tests into a shared repository several times a day
(Check out Chapter 11 for more information about Extreme Programming). By integrating regularly,
people can detect errors quickly, and locate them easier.
Check out Chapter 11 for more information about Continuous Integration.

TESTING techniques
DANGERS OF INVERTING THE SEQUENCE
One practise we have broadly seen when people begin using TDD is that they start inverting the
sequence, it means, writing the code first and test after, as it looks more natural and
consistent. Even if it appears to be a naïve change, it creates a different outcome and a huge
number of undesired consequences. Under these conditions, Tests no longer affect the way
that developers think about the solution as they start focusing on small parts of the code instead
of the possible edges of the solution.
Additionally, tests may also turn out to be optional making portions of the code untestable or not
“safe”. As a result of that, the product becomes less sustainable in the long term as it stops
supporting the idea of quality, simplicity or embracing the change.

TAKE AWAY
REMEMBER
 Create a repeatable and reliable testing process and, if possible, automated.
 The whole team is responsible for quality.
 Defects are easy to fix if you use tests.
 Code is documented by the test.
DEEPEN YOUR KNOWLEDGE
 Agile Testing Book
 EasyMock, Mockito, JMock
 The Role of the Agile tester
 Test-driven Development
 Behaviour-driven Development
BENEFITS
Helps ensure a quality product during the whole development process, not only at the end.
The whole Team focuses on the quality of the product, at all moments.
Encourages face-to-face communication between all Team members.
Automated tests provide confidence to the Team to make changes safely.
Everybody in the team does testing; not merely the testers.
As more tests become automated, this allows for specialised Testers to work on other important areas,
such as the Acceptance Criteria of User Stories.

AWB - 12 - Agile Testing

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to AWB - 12 - Agile Testing (20)

Recently uploaded (20)

AWB - 12 - Agile Testing