At the beginning of this year I was fortunate to be drafted into a team with the task of enabling them to sucessfully use a new-to-the-bank tool called Twist developed by ThoughtWorks.
What is Twist, and what other tools is it like?
To quote ThoughtWorks
Twist tackles the biggest problems that prevent most companies from building an automated regression suite that can keep pace with their complex changing application. Twist helps teams create maintainable, understandable test suites while providing a bridge from manual to automated testing.
Testing can be the biggest hurdle in any organization’s journey towards continuous delivery. Most companies fail to cycle through testing, acceptance and regression quickly enough to release at the speed they need to.
In my own words
Its a thing, that lets you test things repeatedly, in a nice easy to read way.
Its an eclipse based tool, where simple semantic language is converted into pragmatic repeatable tests via. an adapter, using the adaptor pattern.
What is it like
Quite simply its a bit like a cross between an early version of Cucumber (with the plain text structure of requirements) and Fitnesse (with the use of the adaptor pattern).
What does it look like?
Given Thoughtworks Twist out of the box
When I load google
And do a search for agile 78
Then I can get a feel for Thoughtworks twist with its in-built selenium
As an Agile practicioner
I want to load google and do a search for agile 78
So that I can test drive Thoughtworks Twist with its in-built selenium
#I want to load google like so "http://www.google.com"
#I want to search for "agile 78"
#I want to click on the first page and confirm it contains "Robert Elbourn"
This is the bit thats a bit like Cucumber, however what Twist then does is enrich it to make it look a little less like a textpad file, and instead something that looks more marked up / flashy /corporate / dare I say enterprise?
Anyhow you will see there are 3 main sections in the page. The top section containing tags, context, workflow and execution buttons, this I don’t touch in this blog. The middle section, this contains your user story, or your business meaning, the value you are trying to achieve with your working software.
The bottom section is the framework for the code.
In this case Browser Search becomes your java class, and each unique following line transcribes to the methods of the Browser Search class. The light brown lines simply show unimplemented methods, and the black lines are implemented in the above mentioned class.
The code (adaptor)
Getting to work with Jenkins
Was nothing short of a pain but we did it.
If you like us are using Maven with “Poms” then there is no direct integration with ThoughtWorks Twist. All is not lost however as ThoughtWorks does provide an ant build file which then plugs into maven using the “maven ant run” plugin. ThoughtWorks also provides a rudimentry maven script but I couldn’t get it to work, so I did my own.
Nice Reporting but lack of direct compatibility with Sonar
When we got the twist tests running as part of the larger project Pom, we discovered that if any of the twist tests failed the build went red. Initially I was thrilled but I wasn’t so popular with the developers who pointed out that when the build goes red, they get no feedback from their Sonar tests, which would otherwise have gone Yello with an indication of how many failing tests in a nice visual way (i.e. it built but some tests failed). The short term solution was to separate the POMs for better test feedback granularity on the unit tests existing in other modules of the project.
Twist actually provides pretty good reporting in its own way. It actually takes screenshots of any pages where errors are discovered (really really handy I mean how many times have you been served up a defect by a tester with no screenshot of the discovered problem) and compiles them into a report which can be viewed locally, or remotely on a server. I managed to alter the script somewhat and for every seperate build we had a versioned report which was then served up by Apache and accessed via a hyperlink to from the console logs of the Twist module in Jenkins. Heres an example:
You just have to accept that Twists tests in our project context are automated acceptance tests and need to be considered seperately to the unit tests. While this is fine, I have to be aware that some extra work is required putting all of these metrics together to give to the stakeholders.
It doesn’t guarantee BDD … but could support it
Just as sitting in a car doesn’t guarantee that you are a good driver, or even a driver; having Twist in your project doesn’t guarantee you are doing good BDD or even BDD at all. The question is, if you were doing BDD and were given Twist, would it help? assist? be neutral or get in the way?
I actually believe it will help, yes. However its the team that drives the tools, and not the other way around, the team needs to choose the tools whether its Cucumber, Gherkin, JBehave or FitNess or whatever. Sticking to one tool is probably enough, and if you are looking to improve BDD, then your primary focus has to be on your people on the project rather than the tools.
If you are trying to get someone in your company to buy into it, apart from its slightly pricy license cost (around 500 per floating user per year**) it will sell well to the management, this is because of its packaging, its reporting, the fact that it looks fairly slick and “enterprise” and not something developed and designed and understood by developers only. Confidence and presentation is a huge thing and Twist is not weak in this area.