HTTPS clone URL
Subversion checkout URL
A marginally less aggravating alternative to Cucumber
Fetching latest commit...
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
Nukumber ======== A marginally less aggravating alternative to Cucumber Note that this is very much a personal hobby project at the moment; you use it utterly at your own risk. After using Cucumber for a few months I got tired of problems with collisions in the vocabulary of step names. I know that a ubiquitous language is supposed to take care of such problems, but sometimes you're not in a position to affect the language used on your project, and sometimes your project is so complex that semantic overloading becomes likely if not inevitable. So, if two steps are called the same thing but only do NEARLY the same thing, you can end up with lots of horrible shared state and context conditions. I still wanted to be able to run tests from feature files, which are a really great method of communication and a good artefact of specification, but I needed to get away from the shared step definition paradigm. Nukumber enables me to write a single, distinct method for each feature element (background/scenario/ scenario outline) while still requiring adherence to the feature file. For example (and included in the RSpec for the gem), the silly feature file: Feature: Ruby arithmetic functions Scenario Outline: Addition Given I have integers <a> and <b> When I add them Then the result is <result> Examples: Easy sums | a | b | result | | 1 | 2 | 3 | | 5 | 9 | 14 | Can be addressed by an equally silly Ruby file: def addition a = $example['a'].to_i b = $example['b'].to_i pass 'I have integers <a> and <b>' result = a + b pass 'I add them' fail unless result == $example['result'].to_i pass 'the result is <result>' end So, what's the point of all this? The method is a test definition, not a step definition. It's similar to RSpec or XUnit. I don't need to save any of my work in a broader scope to pass it between steps, and the vocabulary of the steps can gloss over unnecessarily complex context or detail. That may not be great from a pure BDD perspective, but it's helpful when you're a tester on a complicated legacy system. What's common with Cucumber? * I must still tie the test code to the progression of passing/failing steps. * The test definition should still act as a thin translation layer between the Gherkin and my Ruby test classes. * If the feature file changes, the test will fail. * I can still pass data into my test code from the Gherkin (any step arguments can be found in $args, and the current example for a Scenario Outline is in $example) * I can specify where my feature and definition files are to the Nukumber CLI. This means I can easily work on Cukes and Nukes on the same project if necessary. * I can still tag my features and scenarios and run them by tag. * I can still write feature files and have the runtime generate test definition boilerplate.