Concordion Plus
I've written in the past about Using English to write Acceptance Tests and the tool I choose/advocate is without doubt Concordion. Customers love seeing their stories come alive, but I've found developers can sometimes struggle to differentiate these from JUnit tests, particularly since JUnit is used to provide the execution mechanism.
I've also found that in many of the situations/organisations where I have introduced Concordion, a single story has required several tests and although the Concordion guide does present some excellent techniques to deal with this, teams new to writing acceptance tests will be uncomfortable capturing stories in this format and customers might not be happy that all their acceptance criteria are being met. I am therefore pleased to be releasing Concordion+ to the wild. At the moment it is a simple extension to Concordion which allows developers to create individual scenarios (or test cases) within a single story and also to ignore the scenarios they are actively working on. In addition, a new JUnit runner captures the state of each of these scenarios independently and reports them in the common IDEs while also allowing developers to use the JUnit @Before and @After annotations. This should simplify adoption by developers since they now have a JUnit lifecycle they understand.
I have to send a huge thank you to Nigel Charman for the concordion-extensions project which helped immensely with my development. And of course I can't dare not mention the excellent work by David Peterson on Concordion itself and particularly the facility to write extensions 😉
I hope you enjoy using it as much as I enjoyed creating it...
Why you should never employ a techie to solve your problems!!!
I've just read a fantastic debate on the usability of Git (or rather the lack of) and it reminds me that most technical folks I encounter are too clever for their own good and will constantly introduce complexity for the sake of it (or to keep their souls clear from the devil - users).
The problem with this is that these wannabe rocket-scientists are fundamentally too stupid to appreciate that real people may not care about the elegant layers of abstraction or powerful combinations of wacky commands that can yield amazing powers. What they want is a simple solution to the problem they have expressed. The technical folks I admire are the technical folks who can create a simple, usable solution in a format that is acceptable and digestible by the end user.
As Einstein quoted "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction.", which indicates the technical community appears to be filled with lots of intelligent fools...
And just to illustrate this further, I would include Spring in the mix here as an (actually it's a collection of) overly complex solution(s) to a fundamentally simple problem space, which given the size of the user community indicates their are a lot of intelligent sheep...