|
IntroductionForBusinessPeople
Tumbler introduction aimed at business folk. No tech-talk here.
Featured Tumbler introduction for business peopleIf 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. 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 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 ReportsTumbler 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:
Story: Comparing items from the same 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): And here is a report for one of the stories: As you can see the reports can also serve as a project documentation. So to summarise, Tumbler:
|
Images work now.
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
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
Thanks for the information.
Regards Mandar P. Sabnis
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
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.