Story Test Driven Development

Story Test-Driven Development

Introduction

Story Test-Driven Development (STDD) is an extension of Test-Driven Development (TDD). While TDD focuses more on the unit testing level, STDD starts from higher-level acceptance tests. STDD has the following components:

1. System Specification: This is the document that describes how the system is expected to behave. It is written in the customer's language, and can be manageable by the customer. This means he should be able to read it or modify it easily. We use HTML as the format to describe the system specification.
2. Acceptance Test Fixture: The fixture reads in the specification, and runs the system to check whether the specification is met.
3. Unit Test Cases: These are the tests specified by the developers. The developers use unit-test cases to guide the development and make sure the program runs as expected.
4. Story Test Results: This reports the status of the acceptance tests.

The relationships among the components are presented in the figure below.
insert the diagram here

The STDD process can be described as follows:

1. The customer writes the system specifications.
2. The developer writes a skeleton class for the test fixture. We call this the "focus specification."
3. Run the acceptance test. Because the system is not implemented yet, the test result will show a lot of errors.
4. Write a unit test for a subset of the system that's addressed in the focus specification.
5. Run the unit test. It will fail because the system is not implemented yet.
6. Implement the system so that the unit test passes.
7. Refactor the code and unit test to remove all redundant code.
8. Run the acceptance test. Part of the test may pass because part of the system is implemented.
9. Repeat steps 5-8 until the acceptance test for the focus specification is passed.
10. Repeat from step 2. Choose another focus specification until all specifications are implemented.

There are some automated testing tools we can use:

• FIT is used to run the acceptance test fixtures.
• xUnit (like JUnit for Java, or CppUnit for C++) is used to run the unit tests.

Writing Specification

The specification is put in org.sangam.test project, under /stories/specs folder. Here is one example:

This test checks that data transmitted from the driver goes to the navigator.
Insert an example here

In the next section, we will see how to write a test fixture corresponding to the table above. For more details about writing FIT tests, please visit http://fit.c2.com.

Writing Acceptance Test Fixtures

In the second row of the table, we see that the fixture is writen in a Java class called org.sangam.BasicTypingTransmission. This class is also located in org.sangam.test project. In this class, we can see the following methods:

• The constructor: Any initialization that needs to be done can be done in the constructor.
• void drightTypes(String): In the table, we can see several rows of the form "enter - dright types - something." When FIT sees enter in the first column, it will call the fixture's method corresponding to the text in the second column (in this case, it's drightTypes), and pass the String in the third column as the argument.
• String vidhyaDisplay(): In the table, we can see several rows of the form "check - vidhya display - something." When FIT sees check in the first column, it will call the fixture's method corresponding to the second column (in this case, it's vidhyaDisplay), and compare the return value with the string in the third column.
• void disconnectDrightAndVidhya(): If the first column is press, FIT will call the method corresponding to the second column (disconnectDrightAndVidhya) without any arguments.

This is just a short description about Action Fixture (as specified in the first row of the table). There are several other fixtures we can use with FIT. For more information, please visit http://fit.c2.com.

Implementing the System with TDD

With TDD, we write tests before we implement the system. Now we have acceptance tests. However, the system is not implemented yet. When we run the acceptance test, we will see several errors. Before we write any code to pass the acceptance test, we need to write some unit tests. We use JUnit for unit testing. We put the unit tests of Sangam in the org.sangam.test project, under the org.sangam.domain package. For more information about test-driven development, you can read Kent Beck's book: Test-Driven Development: by Example. For more information about JUnit, you can visit JUnit's website http://www.junit.org.