If you aren't familiar with it, Cucumber is a BDD Testing tool that uses Gherkin to structure English like text into executable tests. It wouldn't be uncommon to find a test like this someplace;
Feature: Reverse Words in a String | |
In order to read backwards | |
readers must have the words in their text reversed | |
Scenario: Empty String Reversal | |
Given a String Reverser | |
When I reverse the string "" | |
Then the result is "" |
In some cases these tests are just plain awesome for communicating clearly what the expected behavior of some code is.
Cucumber provides a mechanism for using tables to pump data through a test. This is more or less the equivalent of using a loop or a parameterized test. Its not a great idea.
Using a table to load several instances of a structure in order to feed a method some data is fine. Thats setup. But when you are in essence saying, this table represents several independent assertions about the aforementioned code (that also had several tables to create this output); you're doing worse than a loop, your mashing the setup and the assertion of several tests into one place.
Best of Luck.
If you think the aforementioned is OK, best of luck. I've seen this run rampant more than once and the result is that nobody knows what is specifically broken, just that something is broken.
A Clear Path
For each condition that should be true (at any level of testing) there should be more or more tests that verify that condition explicitly and that is it. So, rather than use a set of tables to keep your Gherkin short, have lots of little tests that explicitly call out the conditions that should be true. Mind your testing triangle of course, but for those things that are important, maintaining each one explicitly will serve better for clarity, understanding, and maintenance.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.