First of all, thank you all for coming! With a bit more than 30 people, I heard that this was the largest number of people joining the Meetup. Second of all a big thanks to the folks at Doo for providing a great location, support, beverages & food. I really enjoyed the hour speaking & coding as well as the great 3 hours of discussion & talking afterwards.
Without further ado, these are the (German only) slides: test-automatisierung_bonn-agile_april-2012.
As the main technical part, I presented my preferences about organising automated test (or checks, if you prefer that term) in Cucumber:
- I like to have the scenarios to be as high level and close to the ‘business language’ as possible.
If a user with certain rights or a given role needs to login, I’d rather note that role/right, not an explicitly given username & password in the scenario file.
- I also prefer the step definitions to be as clean as possible. Sure, we likely need to refer to a concrete user name here, and be clear about what steps (on the application level) are done in which order. Assertions (of whatever kind you prefer) is also what I like to see in the step definitions: What is actually done and what the expectations are — that’s what I prefer here.
Code I don’t like in step definitions: Statements that create a browser (headless or otherwise), HTML or XML parsing code, SQL statements of whatever kind…
Whenever that appears in the step definitions, I lose track of what I’m about to check.
- As the details of dealing with the output of the system under test have to go somewhere, I usually create classes and/or modules wrapping all the details. This code actually implements the interface used to communicate with the tested system.
I didn’t come up with all this, but find it a good way for me to separate technical from business levels. Most of the ideas in fact come from @unclebobmartins Clean Coders videos (and his books about the same topic).