3 ms·
I was heavily involved with the Fit project for a while. (Fit is Ward Cunningham's predecessor to Cucumber. It used HTML tables rather than ASCII sentences.) I
by jdlshore 13y ago
I was heavily involved with the Fit project for a while. (Fit is Ward Cunningham's predecessor to Cucumber. It used HTML tables rather than ASCII sentences.)
I find it interesting, if not surprising, that the Cucumber community is discovering exactly the same issues that we did with Fit: namely, that it encourages brittle integration tests, and that people don't use it for its intended purpose of collobaration.
I've come to believe that these problems are unsolvable.
I worked on and promoted Fit for several years. Eventually, after some deep soul searching, I concluded that Fit (and by extension, Cucumber) is solving the wrong problem. The value of Fit (and Cucumber) comes from discussions with domain experts. The tools encourage a certain amount of rigor, which is good, but you can get that rigor just as easily by discussing concrete examples at a whiteboard.
The actual automation of those examples, which is where Fit and Cucumber focus your attention, has minimal value. In some cases, the tools have negative value. Their tests are fundamentally more complex and less refactorable than ordinary xUnit tests. If you want to automate the examples, you're better off doing it in a programmer tool.
Some people got a lot of value out of Fit, and I'm sure the same is true for Cucumber. They got that value by using it for collaboration and focusing on domain rules rather than end-to-end scenarios. My experience, though, was that the vast majority used it poorly. When a tool is used so badly, so widely, you have to start questioning whether the problem is in the tool itself.
Ward and I ended up retiring Fit [1]. I've written about my reasons for abandoning it before [2] [3].
[1] http://www.hanselminutes.com/151/fit-is-dead-long-live-fitnesse-with-ward-cunningham-and-james-shore http://www.hanselminutes.com/151/fit-is-dead-long-live-fitne...
[2] http://www.jamesshore.com/Blog/The-Problems-With-Acceptance-Testing.html http://www.jamesshore.com/Blog/The-Problems-With-Acceptance-...
[3] http://www.jamesshore.com/Blog/Acceptance-Testing-Revisited.html http://www.jamesshore.com/Blog/Acceptance-Testing-Revisited....
- aslakhellesoy 13y agoI completely agree with you that the most important value with BDD and Specification by Example happens during conversations at a whiteboard. Cucumber/Fit/high level tests aren't fundamentally less refactorable. They have a looser coupling to code than unit tests, so when the production code is refactored they are less affected than xUnit tests. The problem most people make is that they are trying to cover too much with Cucumber. And they use it solely as an automation tool without any collaboration whatsoever. That doesn't work, but it's difficult to get that message across to people. In order for Cucumber and Specification by Example to be used well it is essential to provide tooling that appeals to the most critical piece of the collaboration puzzle: The business analysts (or the people with the requirements). Nobody has solved this problem yet, but I think it is a solvable problem. We're trying to solve it with Cucumber Pro: https://cucumber.pro https://cucumber.pro Let's see how that goes.
- jdlshore 13y agoLooks promising! I wish you the best of luck with it.