This is a mini-blog. I'm working to find a compromise between a tweet and a lengthy essay. I find it difficult to complete longer documents because of an obsession with perfection. So this little experiment is to see if I can create a blog of mini articles. Herein I will talk about many technical things generally related to software development and Agile practices.

16 June 2017

Tables in Your Cukes, Please Stop!

You've probably read some of my posts on Loops, and Parameterized Tests and other things where I talk about clarity in the test suite. I thought I should pay attention to Cucumber (and other similar frameworks) for a minute. 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.