testing – TbeeRNot

Given When Then

Post published:February 19, 2023
Post category:BDD testing

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")
                .given(RosterPeriod.on("2022-09-19").exists())
                .and(User.of("peter").isLoggedin())
                .when(Overview.isAccessed())
                .and(VacationHours.forUser("peter").onDate("2022-09-19").isSetTo(20))
                .then(VacationHours.forUser("peter").onDate("2022-09-19").shouldBe(20))
                .and(WeekTotals.forUser("peter").inRosterPeriod("2022-09-19").shouldBe(20,0,0,0,0,0))
                .and(RunningWeekTotals.forUser("peter").inRosterPeriod("2022-09-19").shouldBe(20,0,0,0,0,0))
                .and(Event.who("peter").what("SetVacationHours").user("peter").rosterPeriod("2022-09-19").detailSubstring("hours=20").shouldExist());
    }

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?

(more…)

TDD; an exercise in frustration

Post published:May 27, 2018
Post category:BDD Java TDD testing unittest

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!

(more…)

I have an idea; let’s write automated tests!

Post published:November 8, 2017
Post category:Java testing UI unittest

In the previous post I wrote about a lecture I did in Utrecht. It was about that companies decide that they “should be doing automated tests”, but are unaware of what that really means. Often the idea is triggered because it becomes apparent that even though a lot of money is spent on (manual) testing and testers, the quality of the releases does not really increase, and automated testing is seen as the answer. Which it is, at least partially.

In my lecture I stressed that automated testing is more than just rolling out JUnit. Automated testing involves careful consideration on what and when to test; a good testing landscape consists of several types of test, from unit tests, to integration tests and UI tests. And more importantly those should be in the correct ratio’s, ideally resulting in the famous testing pyramid (and hopefully not the dreaded testing cone).

(more…)