My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
IntroductionForBusinessPeople  
Tumbler introduction aimed at business folk. No tech-talk here.
Featured
Updated Apr 29, 2011 by lipinski...@gmail.com

Tumbler introduction for business people

If you are a Business Analyst, Product Owner, or simply the business side of any software project, this document is for you. It will briefly introduce you to the Tumbler and give you reasons to ask your developers to include it in the project.

What is Tumbler?

Tumbler is a tool, which will help you cooperate with your development team. How often is it, that developers don't really get what you meant in some requirement description? How often do you get something different than you asked for? And the worst - how often do you realise that it's not exactly what you meant, when the software is already deployed? Tumbler will ease the communication between you and the team and will help you prevent such situations.

Tumbler is so called Behaviour-Driven Development tool. It means, that YOU drive the code development by specifying how you'd like the application to behave. You probably think you already do that - in the end it's you who defines requirements. Yep, to some extent you're right. But you don't drive the development, you just give it one big kick. Now what I mean by driving is defining the requirements in such a way, that you can be sure their implementation reflects your ideas. How can that be achieved?

How to use it?

You start with defining stories - minimal features, that you can sell or you just care for.
Let me give you an example: say you're in the internet shopping business. What are minimal features you might want to have in your application? It can be adding things to the shop (as an admin), having stuff divided into categories, comparing items from the same category (as a user), etc.
For each of these stories you can define a set of scenarios (I'm sure you do it anyway, just in a different form). A scenario is an example of use of a story, or in other words a behaviour of the thing you're dealing with.
Again an example: let's take the story 'As a user I want to compare things from the same category to be able to choose the better one'. Now you can specify scenarios like: given that there are two tea types in a 'teas' category, when a user compares them, then they see teas' photos, names, contents and prices. Or another one: given there's only one coffee in 'coffees' category, when user wants to compare coffees, then they see a message that it's impossible.

Great - that's basically it. You only need to write these stories and their scenarios in normal text file and give them to your developers. Hm, actually it would be much better if you could define them together with a developer, to make sure you did not miss anything obvious to developers but not for mere humans.

So, say, you have a file like this:

 Story: Comparing items from the same category
 

Scenario: should compare if there are at least two items in a category Given there are two teas in 'teas' category When user compares them Then they see teas' photos, names, contents, and prices

Scenario: should not compare if there's less then two items in a category Given there's one coffee in 'coffees' category When user wants to compare it Then they get a message 'not enough items in this category'

This form is required - the keywords are Story:, Scenario:, Given, When, and Then. They need to be in different lines, but otherwise you can format it as you want (with any number of spaces, tabs and newlines) to make it readable for you. You can have one file per story, but equally well can define many stories in one file - just place them one below another.

Now that the stories are ready, give them to your development and ask for an always up-to-date report accessible somewhere in your intranet. They will generate Java tests from your stories and will fill them up with calls to the application, to prove that a scenario is working.

You can use your native language if you need to. This is how it looks in Polish:

 Historia: Porównywanie produktów w tej samej kategorii
 

Scenariusz: powinien porównać gdy są przynajmniej dwa produkty w jednej kategorii Zakładając że są dwie herbaty w jednej kategorii Gdy użytkownik je porówna Wtedy zobaczy zdjęcia, nazwy i ceny herbat

Scenariusz: nie powinien porównać jeśli jest mniej niż dwa produkty w jednej kategorii Zakładając że jest jedna kawa w kategorii 'kawy' Gdy użytkownik chce porównać Wtedy dostaje wiadomość 'nie wystarczająca liczba produktów w tej kategorii'

Reports

Tumbler can currently generate two kinds of reports - plain text and HTML.

The first one is in exactly the same form as you gave to the development - it's just plain text, but next to each scenario you have an information about its status. This can be one of three:

  • PASSED - means that the scenario is implemented and its test is passing,
  • FAILED - means that the scenario has been implemented, but for some reason is not working properly - most probably as a sideeffect of some other change to the application (so you have also free regression testing)
  • PENDING - means that the scenario has not been implemented yet
So your story's report would look like this:
 Story: Comparing items from the same category
 

Scenario: should compare if there are at least two items in a category [PASSED] Given there are two teas in 'teas' category When user compares them Then they see teas' photos, names, contents, and prices

Scenario: should not compare if there's less then two items in a category [PENDING] Given there's one coffee in 'coffees' category When user wants to compare it Then they get a message 'not enough items in this category'

The HTML report can have basically any form. There's one default template integrated with Tumbler, but you can ask your developers to create your own. Any template must have 2 kinds of pages: Table of Contents which lists all your stories, and Story page, which shows all scenarios of a story.

Here is ToC with all Tumbler stories (yep, Tumbler is itself driven by Tumbler stories):

As you can see, the ToC contains overall run statistics - how many stories passed (a passing story is one in which all scenarios pass), how many failed (at least one scenario fails) and how many are pending (at least one scenario is still waiting for implementation). Below it there's a table with links to consecutive stories with their status info.

And here is a report for one of the stories:

This one contains all the scenarios of the story together with your description of the behaviour and status information.

As you can see the reports can also serve as a project documentation. So to summarise, Tumbler:

  • helps you think about the requirements,
  • helps you communicate your thoughts to the development team
  • helps the team to implement exactly what you need
  • helps you keep track of the implementation progress
  • helps new project members to learn what the project is about
Isn't that really a lot?

Comment by project member lipinski...@gmail.com, May 23, 2010

Images work now.

Comment by mandarps...@gmail.com, Jan 3, 2012

Hi all,

Can anyone tell me does Tumbler has support for groovy scripting. If yes then how we can do that. Please let me know if is there any workaround on it. I will be very much thankful if any one provide me the details on it.

Thanks & Regards Mandar P. Sabniss

Comment by project member lipinski...@gmail.com, Jan 5, 2012

Hi, there's no special Groovy integration for Tumbler. It should be working just out of the box (isn't it?) Still, if you're using Groovy, you may consider using Spock or EasyB, since they make heavy use of the Groovy flexibility to build DSLs, and are usually more readable.

Pawel

Comment by mandarps...@gmail.com, Jan 16, 2012

Thanks for the information.

Regards Mandar P. Sabnis

Comment by ckelly...@gmail.com, May 26, 2013

Hi,

I like your tool very much. I have two questions.

In the HTML page you can see the report for pending, working or failed. When there is a failure, how do we see the cause of the failure? All that's shown is the red mark but it would be good if you can drill down into the actual JUnit failure. Presently I have to look at a separate surefire report to work out why the failure occured which is not very user friendly.

Is there another way to direct the tumbler reports to another folder. I tried changing the settings but report always goes to target/Tumbler-reports/?

Am I right in thinking that as long as I use the same @Story annotation, I can split up the scenarios into multiple files. Some scenarios need some boiler plate which obscures the test but makes the class file very long if all the scenarios are in the same test class. If I split them up but use the same @Story annotation value, will the report get generated correctly.

Thanks in advance for any guidance offered,

Chris

Comment by ckelly...@gmail.com, May 29, 2013

I've tried using the same @Story annotation on different files but it doesn't work for the tumbler report.

i.e.

Test file A had annotation @Story("Story1") with 3 scenarios Test file B had same annotation @Story("Story1") with 2 scenarios

Report:

Tumbler report shows duplicated Even though I had different test scenarios in each file, the report duplicated one of the tests so it shows scenarios from Test File A twice and completely ignores all the scenarios from Test File B.

The reason I'm pursuing this as I see that the test file can be become very long winded if the story has a lot of scenarios which is a realistic case. I have a story with 10 scenarios and I can see that the generated code result in a very long class. I'd like to split the scenarios into separate classes for clarity and ease of maintenance.

Powered by Google Project Hosting