The FitNesse Fix
Getting the most out of Fitnesse



                         gojko@gojko.net
                            ...
A good acceptance test is

 Focused on a single thing (rule, step..)
 Specification, not a script

 Self-explanatory

...
How - script

rate change date is 23/5
due date                 rate   amount
22/4                  5.40%      340.2
22/5 ...
What - specification

due date   rate changed change reflected in period
22/5                 23/5                       n...
Often easier to spot gaps:

due date   rate changed change reflected in period
22/5                 23/5                  ...
Another example of “how”
   Mike logs on
   Mike browses to the books page
   Mike adds “Perfect Software” to the cart
...
Further Fitnesse advice:
   Don’t let Fitnesse become just another test tool
   Use it as a communication medium
   Rem...
Simplicity
   Hard to do ≠ hard to describe
       “...landing a man on the moon and returning him
        safely to ear...
Common symptoms of problems
   Technical tests
      Reflect the way the code was written
      Use technical jargon/clas...
Common symptoms of problems
   Long/complex tests
      Specify too much (how not what)
      Check for every possible ca...
Common symptoms of problems
   Lots of tests with minor differences in some
    values
        copy/paste?
        How, n...
Now, let’s read some tests
Strategies for simplicity
   Use collapsible sections to hide distractions
      !**> Given a smoker Bob aged 50 with sta...
Interdependent tests
   Copy/paste?
      Common dependencies?
      Parts used to set up/clean up after related tests
 ...
Tests that fail intermittently
      Unreliable
      Asynchronous processes?
      External dependencies?
      Problems ...
FitNesse Pages tell us “what”

     Fixtures handle “how”
As a rule of thumb:
   FitNesse pages should be relatively short
      Specification must be easy to understand
   Stuff...
Best practices to keep tests good:
   Keep in the same SCM as the code
   Keep them organised and easy to find
   Evolv...
Simple Test Design Advice:
   Uncle Bob Martin (TDD rule #2)
       “Don’t write any more of a test than is needed to
  ...
The Fitnesse Fix
Upcoming SlideShare
Loading in …5
×

The Fitnesse Fix

2,645 views

Published on

The Fitnesse Fix

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,645
On SlideShare
0
From Embeds
0
Number of Embeds
501
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

The Fitnesse Fix

  1. 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. 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
  3. 3. 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
  4. 4. What - specification due date rate changed change reflected in period 22/5 23/5 no 22/5 20/5 yes
  5. 5. 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 ????
  6. 6. 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?
  7. 7. 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
  8. 8. 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
  9. 9. Common symptoms of problems  Technical tests Reflect the way the code was written Use technical jargon/class names Favour reuse over clarity
  10. 10. 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
  11. 11. 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
  12. 12. Now, let’s read some tests
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. FitNesse Pages tell us “what” Fixtures handle “how”
  17. 17. 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
  18. 18. 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
  19. 19. 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”

×