However, when testing small systems where there is only one specification per context, the testcase-class-per-fixture syntax becomes overwhelming and cumbersome to user.
For this reason I’m sometimes using a more compact format for the specifications:
||The system under test (SUT), will often be a method name
||The expected outcome of the given context
The disadvantages of using this style is that the method names in the test class may get very long, and the test results output isn’t formatted as good as it would have been when using one test case class per fixture:
The following ReSharper live template can be used to quickly add new specifications/tests:
This post is a summary of a lightningtalk I held for some of my colleagues at Objectware back in August 2008.
What is Arrange, Act, Assert (AAA)?
AAA is a way to organize your tests. The contents of the tests are divided in to three parts:
- Arrange: Do the necessary setup required for running the test. Usually multiple lines of code.
- Act: Execute the code which should be tested. Should be one line of code.
- Assert: Verify that the code behaved as expected. Should contain only one assertion.
Example of a test without AAA
The same test written in AAA style:
The example above is simple, but the value of using AAA style becomes more apparent for complex tests.
Why using AAA syntax
AAA and mocking
In the following example, which parts of the code are arranging, acting and asserting?
The record/playback style should not be used, since it results in tests which are very hard to read and understand.
The same test as above written in AAA style:
Mocking frameworks supporting AAA syntax
The following mocking frameworks supports AAA:
- Rhino Mocks 3.5
- Typemock Isolator 5.0