Test Design

Having had a look at the testability framework, the Test Tool, and the standard tests and libraries, I have shown you what is available in the platform and the application that will allow you to create and execute automated tests. And that's what we are going to do in this part of this book. But let's step back and not just bluntly dive into creating code. Firstly, I would like to introduce a couple of concepts and design patterns that will allow you to conceive your tests more effectively and efficiently. At the same time, these concepts will make your tests not just a technical exercise and will help you to get your entire team involved.

I am surely not going to bother you with formal test documentation and the top-down approach with eight defined stages, from test plan, through test design/case specification to test summary report. That's way out...

No design, no test

Goal: Understand why tests should be conceived before they are coded and executed.

I guess I am not far off saying that most of the application testing done in our world falls under the term of exploratory testing. Manual testing is done by experienced resources that know the application under test and have a good understanding and feeling of how to break the thing. But this with no explicit design and no reproducible, shareable, and reusable scripts. Now, in this world, we typically don't want developers to test their own code as they, consciously or unconsciously, know how to use the software and evade issues. Their mindset is how to make it (work), not how to break it.

But with automated tests, it will be developers that will code them. And more often than not, it will be the same developer that did the application coding. So, they need a design of what...

Understanding test case design patterns

Goal: Learn the basic patterns for designing tests.

If you have been testing software, you might know that each test has a similar overall structure. Before you can perform the action under test, for example, the posting of a document, first, the data needs to be set up. Then, the action will be exercised. And finally, the result of the action has to be verified. In some cases, a fourth phase applies, a so-called teardown, which is used to revert the system under test to its previous state.

The four phases of a test case design pattern are listed as follows:

• Set up
• Exercise
• Verify
• Teardown

For a short and clear description of the four-phase design pattern, please refer to the following link:
http://robots.thoughtbot.com/four-phase-test

This design pattern was typically the pattern used by Microsoft in the early years of C/SIDE test coding...

Understanding test data setup design patterns

Goal: Learn the basic patterns for setting up test data.

When you carry out your manual tests, you know that most of the time is consumed by setting up the right data. Being a real IT pro, you will think up ways of doing this as efficiently as possible. You might have thought of making sure of the following:

• A basic setup of data is available, which will be the foundation for all of the tests you are going to execute
• For each feature under test, additional test data exists upfront
• Test specific data will be created on the fly

This way you created yourself a number of patterns that help you efficiently get your test data setup done. These are what we call test data setup design patterns, or fixture or test fixture design patterns, and each has its own name:

• The first one is what we call a prebuilt fixture. This is test data that...

Using customer wish as test design

Goal: Learn why to describe requirements in the form of a test design.

A past ideal of development was a staged one, where each phase would finish before the next started. Just like a waterfall, with water flowing from one level to the other. From requirements gathering to analyses, to design, coding, testing, and finally, operation and maintenance, each phase would have its deadlines, and documented deliverables handed off to the next phase. One of the major drawbacks of this system is its responsiveness to changing insights, resulting in changing requirements. Another is the significant overhead of documents produced. In the recent decade or two, agile methodologies have become a general practice for tackling these drawbacks.

Introducing a test design, an extra document, to your development practice is maybe not what you have been waiting for...

Summary

Test automation will profit from a structured approach and, for this, we introduced a set of concepts and test patterns, such as the ATDD pattern and test fixture patterns.

Now, in the next chapter, Chapter 5, From Customer Wish to Test Automation – The Basics, we will utilize these patterns to finally implement test code.