Given When Then

  • Post category:BDDtesting

I have a love-hate relationship with Gherkin, the syntax underpinning Cucumber tests. On the one hand I love the readability, on the other I find the binding of the sentences to step definitions flaky, and the lack of formal structure in those sentences worries me. Like the Maven vs Gradle debate, I’m a fan of structure; it keeps stuff from derailing quickly. (Maven FTW.)

So when I decided to give Cucumber another go for one of my hobby projects, I attempted to get some structure in (more on that later on). But the result was that I wrote this:

    public void test() {
        Scenario.of("Modify Vacation Hours")

Which is the Java equivalent of this Cucumber test:

      Scenario: Modify Vacation Hours
        Given a rosterperiod 2022-09-19 exists
        And user peter is logged in
        When the overview is accessed
        And the vacation hours for peter on 2022-09-19 is set to 20
        Then the vacation hours for peter on 2022-09-19 should be 20
        And the week totals for peter in rosterperiod 2022-09-19 should be 20,0,0,0,0,0
        And the running week totals for peter in rosterperiod 2022-09-19 should be 20,20,20,20,20,20
        And an event with who "peter", what "SetVacationHours", user "peter", rosterdate 2022-09-19 and detail substring "hours=20" should exist

And I started wondering if the Java version is readable enough. Because it damn well fixes all my issues I have with Cucumber.

What do you think?


Continue ReadingGiven When Then

TDD; an exercise in frustration

Recently I read an article about How to TDD a List Implementation in Java and it suddenly reminded me of an experience a colleague made me go through a few years back. At that time the company I was working for had a big piece of software with almost no automated tests, and they (of course) had stability issues. So I was an advocate of starting to write automated tests; by developers, by testers, unit tests, UI tests, the works, in an attempt to get the software stable.

After a year of hard work solely focused on bug fixing and writing tests, it finally started to pay off. (Yes, that is what it takes; the company decided to not release any new features for a whole year, but in the end it paid off big time. Major growth in market share, because clients took notice. But it took guts to choose that path.)

Testing had become common practice by then and at one point a colleague came up to me and asked me what I though about Test Driven Development (TDD). I said that it didn’t feel right, so he asked me if I wanted to give it a try.

Well… Of course!


Continue ReadingTDD; an exercise in frustration