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
Utils anti-pattern & AutoMapper
These are more for my reference purposes – hopefully you’ll find them useful:
If you’re about to name a class **Util; think harder – there is a better name that discribes what that class is for:
Chriss Missal has some advice for you
Faced with the prospect of heaps of left hand side => right hand side code in your DTO of anti-corruption layer? Consider Jimmy Bogard’s Automapper
Functions with side effects are just rude!
Today I fell into a trap when using a function that had a side effect – it unexpectedly changed an input parameter; causing a later statement to fail. Debugging took an age!
For example, consider the following function:
1 | string StringReplace(string haystack, string needle) |
If this function is side-effect free, we can use it without fear like this:
1 2 3 4 5 6 | string menagerie = "cat,dog,bee,llama"; string catFreeMenagerie = StringReplace(menagerie, "cat"); string beeFreeMengerie = StringReplace(menagerie, "eric"); Assert.AreEqual(",dog,fish,llama", catFreeMenagerie); Assert.AreEqual("cat,dog,,llama", beeFreeMengerie); |
However, if StringReplace() had the side effect of also changing the passed in haystack, then the second Assert would fail, because the first StringReplace has the unexpected side effect of changing one of its arguments.
Evans in the DDD book has quite a bit to say about this; arguing that having side effect free functions goes a long way towards making a supple design
Side effect free functions also make testing & refactoring easier (less state to worry about etc)
Remember, a function that changes its parameters is rude, and should not be trusted!
