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.

http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468

http://easymock.org/

https://code.google.com/p/mockito/

http://jmock.org/

http://www.slideshare.net/dwhelan/agile-testing-and-the-role-of-the-agile-tester

http://en.wikipedia.org/wiki/Test-driven_development

http://en.wikipedia.org/wiki/Behavior-driven_development

awb - 12 - agile testing

Technology