This is our first track talk for the day. For those who are familiar with cucumber, it is both a cool way to do requirements outlining and a top-heavy tool to write tests with an additional plain language wrapper. Note that both of those statements are accurate and are not meant to be said as a positive or a negative. I've ween Cucumber used well and I've also seen people use it in sloppy careless ways. Chris Cowell seems to agree with me. In Chris' view, a bad Cucumber implementation is worse than no Cucumber implementation.
Cucumber is a free open source tool where you focus on behavior-driven development. Basically, how does the user interact with the program and how can we determine that proper behavior is seen.
Cucumber is based on scenarios and each scenario contains steps. Steps are typically written in a format that emphasized statements set up in a "Given, When, Then" series. Think of something like:
Given I want to log into the system
When I enter my username and password
Then I am on the welcome page
Of course, this is just a series of statements. they don't mean anything unless they have actions behind them. Cucumber has a number of harnesses and frameworks that it can interact with. Ruby and Java are perhaps the most well known but there are implementations for numerous other languages.
Rather than focus on the underlying code, let's consider Cucumber requirements specifically (and its underlying Gherkin language). there are a variety of ways to make scenarios and those scenarios can be made to be complex. Ideally, we would try to avoid doing that. The simpler the requirement and the more readable the requirement, the more likely that scenario will not be misunderstood. Adding too much logic or too many steps will make it difficult to determine if the requirement is actually being met.
Cucumber is also not meant to be an exhaustive system or set of testing options. Plain English sentences are the goal. Look above where I created a simple login example. I could format this so that it looks at entering in multiple usernames and passwords. Is that a good series of tests? Possibly. Is that a good way to test behavior-driven requirements? Probably not. It's also better to focus on what is being done, rather than the exact steps or movements necessary to do every permutation.
Personas are useful and can help make the descriptions more meaningful to all stakeholders. By giving names and personalities we can see how different users may require or expect different behaviors.
Another anti-pattern is to avoid copying and pasting between scenarios. Granted, if done correctly, specific statements should be reusable in as many scenarios as possible. The key is to make sure that the statements made are as generic as possible and if generic doesn't cut it (as in there are terms that are specific to scenarios) then make the general statement as useful as possible without having to make multiple changes.
Scenarios can also have general statements that occur frequently. If you have scenario steps that are identical in different scenarios, it makes sense to extract them to a single location and use a keyword called "background". this background means any and all scenarios using that background will call that statement first and will call it with all of the scenarios listed beneath the background.
This all might seem a bit top-heavy and it's possible for some environments and well-established development environments, it may not make sense to wire up a full Cucumber test framework. Still, even if you don't actually run these Gherkin statements as literally automated tests, it is still useful to think of the phrasing and actions associated with Cucumber statements. these phrases and syntax may prove helpful when writing your requirements. Just using the base Cucumber syntax for writing out requirements may prove helpful. If you want to go the rest of the way, you could think of doing the rest and actually writing tests that use each requirement statement.
No comments:
Post a Comment