Fitnesse Smell – Executable Requirements that look like Scripts
Gojko (who wrote the Fitnesse book) has this interesting discussion on what makes a good acceptance test in Fitnesse.
http://gojko.net/2010/06/16/anatomy-of-a-good-acceptance-test/
His point seems to be that Fitnesse is a good tool for documenting specifications, and continuously automating their validation. When your Fitnesse tests become like “scripts” (which is how developers are trained to see the world), then Fitnesse is a pretty crummy test execution environment (just use a unit test runner!)
Interesting that alternate tools – http://www.concordion.org, http://wiki.github.com/aslakhellesoy/cucumber/, http://www.specflow.org/ have arisen that effectively try to limit the power of the “test description language” to prevent the acceptance tests becoming script like.
Interesting food for thought – I know that many of my Fitnesse tests exhibit this codesmell
Why Pair Programming Doesn’t Reduce Productivity
The other day I was asked why pair programming doesn’t reduce productivity; and its taken me a few days to come up with a this succinct answer –
because we’re building a system to release software changes rapidly over a long period of time, not type more lines of code to reach some predefined goal post
The purpose of a software team is to deliver a working software solution that solves customer’s problems over a long period of time.
This would be easy if:
- Customers knew what they wanted
- Developers knew how to deliver the features
- The world remained the same on the day the software is released as it was at the time it was designed.
The trouble is that none of these are true. We have to guess at the right solution, get some real world experience with it, and then optimise when we know more about the problem domain (aka, after we have delivered the feature for the first time).
The way to do this better is to reduce the length of the feedback cycle (think 5 days, not 6 months), and grow a system that can rapidly and repeatedly deliver changes to the software over the life (years) of that software.
Pair programming contributes directly to growing this system by:
- Facilitating communication about the architecture & design of the system, and ensuring everyone actually understands it
- Reducing brittleness & bottlenecks caused by one person “owning” a core module
- Improving consistency and adherence to common standards
- Catching bugs at the cheapest time to fix them
Unintuatively, it also tends to ensure that developers actually spend longer working on the software by:
- Reducing “wander time”. You are less likely to get sidetracked into email, facebook or some interesting blog article when pairing.
- Reducing “stuck time”. Two perspectives on a problem have twice as many solutions to try out
These articles go into more depth:
- http://www.menloinnovations.com/freestuff/whitepapers/pairedprogramming_qanda.htm
- http://anarchycreek.com/2009/05/26/how-tdd-and-pairing-increase-production/
To conclude, pair programming would be a unproductive if developers had the perfect solution is their head, and programming was just the task of typing that into the computer to release a single perfect version of the software.
But in the real world we we’re in the business of creating a system that can rapidly deliver changes to the software as it narrows in on, and adapts to the best solution to the problem at hand. And to do this, pair programming excels.
CI for Flex 4; running FlexUnit4 unit tests and FlexMonkey4 acceptance tests with Maven and FlexMojos
The FlexMojos project is a great way to bring your Flex application under a grown up continuous build system like Maven.
Getting FlexMojos 3.6.1 working with Flex 4, running Flash Builder 4’s version of unit tests and FlexMonkey4’s version of acceptance/UI tests is pretty tricky.
Hopefully this sample project – http://github.com/mrdavidlaing/flexmojos-sample along with this screencast will save someone else the pain I went through to get all these playing together.
Howto add new component to FlexITP from David Laing on Vimeo.
Patches welcome – just clone the git repo make your change, and request a pull.
