Suppose that you want to leave something for the humanity, after many sleepless nights you finally discover that it will be a movie database, even more: Internet Movie Database. Now, my Friend, you have two ways: you can start writing this service immediately, forgetting about the eating and sleeping ... When you'll find yourself abandoned by all your Friends, and lost completely in the endless code you wrote, without helpful hand from the tests you were too busy (or even worse, too proud) to wrote ... You'll find the path to enlightenment - second way. Slower, but built on rock solid foundations - ATDD, BDD, and maybe even few more acronyms ;)
Before you yell: "Teach me this way!" few words of explanation. I'm not the Master Yoda. I'm still learning, as you do, and will whole my life, but maybe some parts of my daily exercises will help you somehow ...
Back to the example :) - What we do first, is defining the core functionality required by our service, and describing it in EasyB syntax. Note that in this post we will focus on testing service only. Instead of writing the service, we will use existing Internet Movie Database, and verify if it matches our expectations:
What you see is one of the use cases I assumed for the service. How can we bring it to life now? For example, using Apache Maven, if you decide to choose it as a build system for your project, as I did.
What you need is adding to your pom.xml file few lines defining the EasyB plugin (under build/plugins section):
Now we may try to run this scenario and see what EasyB will tell us. We can do it for ex. with:
mvn clean test easyb:testReport generated by EasyB looks like this one:
Interesting, but the real fun begins with Thucydides usage. First we have to get back to Apache Maven configuration, and change the report type generated by EasyB from HTML to the default one (XML), otherwise there will be nothing to process for Thucydides.
Now we may try to run our scenario in following way:
mvn clean test easyb:test thucydides:aggregateand start admiring report generated by Thucydides, which looks like this one:
 |
| Summary Page |
 |
| Features Summary |
 |
| Stories Summary |
 |
| Story Details |
Now we get to the clue :) - as you probably noticed, some steps defined in the scenario are in pending state. This is the moment when the Business Management Team role ends ;), and starts our own :), because we, as the Developers, have to implement the tests standing behind the scenarios. :)
You may also wonder if Thucydides role here is beautifying the reports only - of course not! - it shows its potential when we start to implement tests :).
Let's return to our scenario description:
First of all, we group all features and use cases of our application in 3 level structure - Application - Feature - Use Cases (Scenarios):
Now we implement the steps defined in scenario for the system:
and for the user:
And finally the code reflecting pages of the service, for welcome page:
and search results:
After implementing the code standing behind our scenario, we can run it again and compare the results with expectations:
 |
| Summary Page |
 |
| Features Summary |
 |
| Stories Summary |
 |
| Story Details |
 |
| Welcome page opened (Given) |
 |
| Title search beginning (When) |
 |
| UI change - Search Type selected |
 |
| UI change - search query entered |
 |
| UI change - form submitted |
 |
| Search results verification (Then) |
Few lectures for the dessert:
