The Fitnesse Fix

1. The FitNesse Fix
Getting the most out of Fitnesse
gojko@gojko.net
@gojkoadzic
David.Evans@sqs-uk.com
@DavidEvans66
Mike.Scott@sqs-uk.com
@MikeAScott

2. A good acceptance test is
 Focused on a single thing (rule, step..)
 Specification, not a script
 Self-explanatory
 Uses the domain language
 About business domain
- Not about software design
 SMART
Specific, Measurable, Achievable, Relevant, Time-bound

4. How - script
rate change date is 23/5
due date rate amount
22/4 5.40% 340.2
22/5 5.40% 340.2
22/6 4.90% 308.7
rate change date is 20/5
due date rate amount
22/4 5.40% 340.2
22/5 5.40% 308.7
22/6 4.90% 308.7

5. What - specification
due date rate changed change reflected in period
22/5 23/5 no
22/5 20/5 yes

6. Often easier to spot gaps:
due date rate changed change reflected in period
22/5 23/5 no
22/5 20/5 yes
22/5 22/5 ????

7. Another example of “how”
 Mike logs on
 Mike browses to the books page
 Mike adds “Perfect Software” to the cart
 Mike adds “Agile testing” to the cart
 Mike goes to check-out
 Mike gets offered free delivery
what are we specifying here?

8. Further Fitnesse advice:
 Don’t let Fitnesse become just another test tool
 Use it as a communication medium
 Remember your stakeholders
 They would not read a test automation script
 Avoid overcomplicating test pages
 What would a newbie learn, browsing your pages?
 XXX rated tests
 Explanatory, exemplary and executable

9. Simplicity
 Hard to do ≠ hard to describe
 “...landing a man on the moon and returning him
safely to earth”
 Separate test Setup from test Actions
 Preconditions are boring, actions are interesting
 “As our story begins...”
 Use a 3-part format to structure complex tests
 Given, When, Then
 Arrange, Act, Assert
 Precondition, Action, Postcondition

10. Common symptoms of problems
 Technical tests
Reflect the way the code was written
Use technical jargon/class names
Favour reuse over clarity

11. Common symptoms of problems
 Long/complex tests
Specify too much (how not what)
Check for every possible case
 These tests are useful, but not as a specification
copy/paste from other tests things that aren't really
needed
 Break them up
 Distil the specification

12. Common symptoms of problems
 Lots of tests with minor differences in some
values
copy/paste?
How, not what?
 Distil “what”, create a single test out of the
whole group
 Let the test highlight the differences that matter

13. Now, let’s read some tests

14. Strategies for simplicity
 Use collapsible sections to hide distractions
!**> Given a smoker Bob aged 50 with standard life policy
Setup tables to create Bob’s life insurance policy etc. go here...
**!
 Let the Fixture code deal with complexity

15. Interdependent tests
 Copy/paste?
Common dependencies?
Parts used to set up/clean up after related tests
 Extract common dependencies into test suites
 Push technical activities into fixtures

16. Tests that fail intermittently
Unreliable
Asynchronous processes?
External dependencies?
Problems in the implementation?
Data dependency?
Random values?
 Work out what's wrong and fix it

17. FitNesse Pages tell us “what”
Fixtures handle “how”

18. As a rule of thumb:
 FitNesse pages should be relatively short
Specification must be easy to understand
 Stuff should not repeat across pages
Don't copy and paste, make specification clear and
focused
 Fixtures should be very thin
Just an adapter to your code
Shouldn't contain logic
Use them to script test workflow

19. Best practices to keep tests good:
 Keep in the same SCM as the code
 Keep them organised and easy to find
 Evolve the language consistently
 Clean up periodically

20. Simple Test Design Advice:
 Uncle Bob Martin (TDD rule #2)
 “Don’t write any more of a test than is needed to
make it fail”
 Brian Marick:
 “Use no word unless it's clearly related to the
intention of the test”
 Bach, Kaner, Pettichord:
 “Avoid complex logic in your test scripts...
keep your tests linear”