There are two common ways of writing automated tests which apply from unit to acceptance tests. These are typically known as test fixtures and Given-When-Then scenarios.
- Traditional method of writing tests.
- The common JUnit/NUnit approach. Other languages have very similar concepts.
- Single test fixture with multiple tests.
- Test fixture is usually named after the subject under test.
- Can grow large with many test cases.
- Works well with data driven tests.
- Suited to solitary tests such as integration tests where GWT syntax would be verbose or hard to include.
- Behaviour driven approach (BDD style).
- Made popular by tools such as RSpec.
- Single test fixture per behaviour.
- Test fixtures named after the functionality being tested.
- Often nested within other test fixtures.
- Smaller test fixtures but more verbose due to fixture per functionality.
- Easy to see why a test failed due to naming convention - assertion message is optional.
- Suited to sociable tests where the focus is on behaviour.
Givenforms the pre-condition of the test.
Whenperforms the action.
Thenincludes one or more related assertions.
- GWT can be difficult to name in some cases, often more thought and discussion can be required around good naming conventions.
- Can act as useful documentation on how the code is meant to function.
- No single way of writing automated tests is better.
- Favour single test fixtures for integration tests.
- The core of your tests can use GWT style.
- Mix and match where appropriate however.
- Your choice of tooling and language may influence your approach.