Implementing Story Acceptance Tests

Summary

Writing story (or acceptance) tests affords your team superior communication, in-depth understanding of the system and how it should be changed (the requirements), and an evolving suite of system tests definitions. Automating these tests, in a way that is accessible to testers, developers and customers alike, will allow you to derive the most value from them. This course is about automating story tests using the Fit framework.

Course Objectives

This course teaches the participants how to automate story tests using the Fit framework. Fit allows tests to be easily automated and at the same time does not limit the vocabulary available for the test writers. At the end of the course the participants will

understand the importance of automating story tests
understand story test driven development (STDD)
understand how to use Fit to implement STDD
know how to use Fit to automate story tests
know how to use Fit as it is distributed
know how to extend Fit to do exactly what they need
understand test interfaces and how to reuse story tests

Description

Defining story tests up front will have an immediate impact on:

the quality of the software being written
the efficacy of the development process
the satisfaction of the customers and the developers

This is achieved by increasing the bandwidth and immediacy of communication within the team as well as promoting a rigorous process of requirements’ analysis. The advantages achieved by story test writing can be further amplified by automating them. This will allow the team

to get an current, immediate indication as to the health of the system – preventing regression
to get a clear indication of the completion of the task at hand
to offload the tedious, repetitive functional tests from the testing team freeing them to devise and execute better system tests.

This could be achieved by any automation framework, but there are other requirements that must be fulfilled

the language used to write the tests should be domain specific and understood by all
everyone should be able to write these tests
the tests must be executable by all

Such a system is Fit. In this course we will cover Fit in details and provide everything that is needed to effectively use Fit to implement story testing.

Simple Language
The language used to specify the tests should be as close to the language used by the customers as possible. We dub such a language Domain Specific. If we use the customer’s language – the customer is able to understand the test and sign off on it. This means that complex script languages are not appropriate.

This also means that the framework used should allow the users to express their needs in the way that most expressive for them. The testing framework should not dictate the vocabulary for the test writers but rather the other way around. It is the job of the technical team members to make that happen and interpret the wording of the tests correctly.

Easy to Write and Execute
You should not be required to invest in large and complex systems in order to implement story tests. The tools used to author the tests should be simple and readily available – like a regular word processor. Likewise, anyone should be able to execute the tests to get an accurate picture of the state of the project. This includes the developers that can see first hand on their own machine whether the system is working as expected or not, by running and debugging the acceptance tests locally.

Simple Project Management
It is a given in STDD that the developers are provided with the test before they commence writing code and that the test is approved and agreed upon by all. This means that once the test passes the team’s task is complete. This simplifies project management considerably because you now have an unequivocal measure of success – the passing of the test. Since the tests run on the developers’ machines, it is not possible anymore to check in incomplete or buggy code – the tests will not allow it.

Different QA
Automating the functional story tests frees the testers to concentrate on new and innovative ways of performing system tests. This ensure a much more robust testing process that focuses on finding new defects rather than verifying that the old ones do not come back.

What does it cost?
Not much. There is little investment in the testing framework and related tools – these are the same tools used by the team currently (with the addition of the free Fit framework). The complexity of writing the fixtures to bind the system to the tests is the responsibility of the technical members of the team. The goal is to make the process as inexpensive and painless to the other members (users/testers) as possible.

Course Level

Intermediate

Course Outline

Story Testing overview
Fit overview
Integrating Fit with your development environment
Understanding vanilla Fit capabilities
Mocking and Fit
Understanding how Fit Works Internally
Extending Fit capabilities to implement specific Domain Specific Languages (DSL)
Fixture reuse by different product teams
Changing the development process to accommodate story testing
- The build
- Source control
- Testing
Dealing with legacy code

Target Audience

This course is for developers, and technical testers – anyone who is involved in the implementation of story tests. The team may work in one of C++, C# or Java, the course can be tailored to other languages.

Room Setup and Equipment Needed

Computers will be used to write tests and execute them. Classrooms require pairs of students to write code using their IDE of choice preferably with an associated unit testing framework (e.g., JUnit/NUnit…) . The Fit framework will be provided.

Courses