Functional Testing

Purpose: Allow decision making (can I commit, can I release), Reduce ambiguity (use domain terminology,

It is often said that we should treat test code as production code. This emphasis is to drive home the point that test code should get same love and attention as we give to the production code. Quite often we use same programming language to write test as we use for writing code. These languages provide all design tools that one needs to solve a difficult problem. Functional testing is may be not a difficult problem but if we go by how (less) successfully it is often implemented, it at least is not trivial. Hence it is important to also think about what is the design of our functional tests.

In this section of the book we would lay down the building blocks which we would use in making our functional test solution. Like any other problem domain, functional test poses problems which are encountered regularly. This warrants that there are patterns for solving these problem. We would look at some of them as well.

Building blocks

UI Element

Screen object

Screen data

User task

Workflow

Patterns

Test design

Running

Analysing results

TestEntity, WithMandatory, Setters returning this,

Use layer super types

Time dependent tests

Defining system boundary, capturing data flowing out the system during test

Structured automation records - Save the test logs to database for analysis.

Practices

Write unit tests for framework code if required

Log to troubleshoot