When doing ATDD (Acceptance Test Driven Development) or BDD (Behaviour Driven Development), the following grammar is widely spread to formulate pre- and postconditions of a test:
- Given: The static preconditions
- When: The behaviour under test (or that, which should be specified)
- Then: The expected results of the behaviour under the given preconditions
In this context executable specifications are a hot topic, but it is still a long way to go, isn’t it?
The goal is to be able to describe a behaviour in such a way, that it is specification and test at the same time. This removes the ever-existing divergence between specifications and what the system is actually doing.
Next to the nearly natural-language like test description, the exact behaviour is only understandable with additional examples. These often differ only in details, which makes the tabular format the recommended one, because there differences can be easily spotted. The combination of the given/when/then-structure and the examples table looks very promising at the moment, based on discussions in the community. It contains all technical details to automate the acceptance test, is compact enough to stay clear from distracting noise and last but not least is understandable to the business people, so that it is suited perfectly for discussing. Maybe it can be even created by the whole team, together with the business analysts, in a so called “specification workshop” (read: “Bridging the Communication Gap”, by Gojko Adzic).
This structure is currently supported by FITNesse as well as Cucumber , so where does the robot framework stand?
With the most recent version of the Robot Framework (2.1.2), there are two improvements, which are key to executable specifications:
- “Given”, “When”, “Then” and “And” are ignored at the beginning of user keywords
- Parameters can be embedded into user keywords
With they you can create executable specifications perfectly. Here’s an example:
1*** Settings *** 2Resource ${RESOURCES}/BDD.txt 3 4*** Keyword *** 5Example 6 [Arguments] ${periodClosed} ${periodOpenAndModified} ${importDay} ${oldManagerValidUntil} ${newManagerValidFrom} 7 8 Given initialized criteria for bonus commercial 9 And a branch B with branch manager M_OLD and employee E1 10 And evaluation for E1 for period ${periodClosed} which is closed 11 And evaluation for E1 for period ${periodOpenAndModified} which is open and modified 12 13 When M_NEW becomes new manager of branch B 14 And import service is called on ${importDay} 15 16 Then the new branch manager of branch B is M_NEW valid from ${newManagerValidFrom} 17 And branch manager M_OLD manages employee E until ${oldManagerValidUntil} 18 And branch manager M_NEW manages employee E from ${newManagerValidFrom} 19 And Evaluations for E1 still have the same content 20 21| *Test Case* | | *Closed Period* | *Open Period* | *Run Import On* | *Old Manager Stops* | *New Manager Starts* | 22| 1 | Example | 1.11.2009 - 30.11.2009 | 1.12.2009 - 31.12.2009 | 11.11.2009 | 30.11.2009 | 1.12.2009 23| 2 | Example | 1.11.2009 - 30.11.2009 | 1.12.2009 - 31.12.2009 | 1.11.2009 | 31.10.2009 | 1.11.2009 24| 3 | Example | 1.11.2009 - 30.11.2009 | 1.12.2009 - 31.12.2009 | 1.12.2009 | 30.11.2009 | 1.12.2009
There you go. A very comapct and clear executable specification. Hard to believe that it is actually executable:
- This is a Robot Test Suite, containing one user keyword “Example” and three Test Cases “”1”, “2” and “3”
- While the test cases use the “data-driven-style “, the user keyword is using the new “behaviour-driven-style “
- Because of the plain text mode, the need for an external editor is vanishing. Quite the opposite, RIDE (Robot IDE) has the habit to reformat the Test Suite and puts the user keyword under the test cases, which is desireable normally, but now destroys the reading and flow through the document.
- Some parameters in the user keywords are variable, like ${importDay}, while others are fix for this test case, like the branch name B. It is essential to keep the examples reduced to the relevant data, to keep it clear and understandable.
- The user keyword “Example” is defined in every Test Suite. Since robot is giving local keywords precedence over user keywords from other sources, this is no problem. Quite the opposite, the layout of the examples table can be kept consistent over all suites.
- The examples table uses the pipe symbol “|” for the layout. This makes it possible to give the columns meaningful names; but the column titles have no effect on how the parameters are passed, only their order is important and has to match the parameters in the row “[Arguments]”
- The concrete test cases are just numbered, improving the compactness of the table
- Test Setup and Teardown have to be somewhot hidden in the first user keyword (here: “initialized criteria for bonus commercial”). On the other hand, it is none of the business’ business how the system get’s into a defined and clear state.
- The executable specifications can be grouped in a directory structure to be mapped to user stories.
Now can these natural language sentences be automated? This is highlighted with the first postcondition. The resource file BDD.txt contains all user keywords, which make this executable specification … executable: :
1*** Settings *** 2Library de.codecentric.fourtexx.robot.ModelKeyword 3 4*** Keywords *** 5the new branch manager of branch ${branch} is ${manager} valid from ${newManagerValidFrom} 6 assert branch manager valid from ${branch} ${manager} ${newManagerValidFrom}
Note that not only the date is parametrised, but also the branch name and manager. In this example the values B, M_NEW and (depending on the test case) 1.12.2009 or 1.11.2009 will be passed. The defined user keyword is barely doing more than forewording to a user keyword, implemented in Java. There you can do what a keyword has to do, in order to assert the required business aspects:
1public void assertBranchManagerValidFrom(String branch, String manager, String validFrom) throws Exception {
2 // ...
3}
Conclusion: With the new possibilities of Robot Framework 2.1.2, it is at least en par with the other contestants in this race. The discovered way to have executable specifications with an appended table for examples in plain text seems to be ideal to make specification, example and test collapse to a single artefact.
Was this post helpful?
More articles
fromAndreas Ebbert-Karroum
18.11.2020 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Andreas Ebbert-Karroum
Agile Principal Consultant
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.