Can I Write Tests?

I’ve previously established that you need to automate your tests, even (especially!) in legacy projects. I’ve also covered on how to get your developers to write tests. But maybe you’re wondering if you or some other non-technical person can help write the tests. Luckily, there is a way, and I would even recommend it highly.

Types of Tests

First, let’s briefly cover the types of tests again. Broadly speaking, the following type of tests exist:

• unit tests: to quickly test small pieces of code in isolation, mainly for developers
• integration tests: to test the integration between different pieces of code, also mainly for developers
• end-to-end tests: to test the entire product with as much pieces of the final software as possible

The last part is where you can fit in. Don’t panic, you won’t have to write a single line of code.

Gherkin

What if you could draft your requirements in a way that allowed a computer to read them and verify the software meets these requirements?

Well, it’s entirely possible. The software to do this is called Cucumber (or SpecFlow if you’re a .NET shop) and the language or syntax is called the Gherkin syntax.

An example will help explain this. The idea is that you write requirements in plain English following a given-when-then structure. Say you have an application that processes freelancer’s timesheets. At the end of the month, you need to know how much to pay the freelancer. A (simplified) requirement could look like this:

Feature: Payment Calculation

    Scenario: Valid Timesheet
        Given an hourly rate of $70
        And a timesheet with entries
            | Date       | in    | out   |
            | 2019-01-29 | 8:32  | 12:14 |
            | 2019-01-29 | 12:58 | 17:21 |
            | 2019-01-30 | 8:45  | 12:01 |
            | 2019-01-30 | 12:29 | 17:07 |
        When the total payment is calculated
        Then the result should be $1118.83

This is a very readable requirement! Developers can now take this text and “map” each part to a piece of code. The first two steps (“Given” and “And”) set up the situation for the test. The third step (“When”) calls a piece of the software passing along the data from the previous two steps. The software will respond with a value which we then verify in the final step (“Then”).

If all is implemented correctly, this test can be run and should pass. After this, it’s no longer necessary to test this manually. But the advantage of this approach goes well beyond automated testing.

These requirements are a readable form of documentation, that are in sync with your current code. If you’re using source control (contact me if you’re not!) you can always go back to a previous version and see what the requirements were then.

Another great advantage is that it connects (technical) developers to (non-technical) business people or end-users. It provides a shared language and a shared space where the two connect.

Great! Let’s Go!

These Gherkin-style tests (also called acceptance tests) are a very powerful tool for any IT department or company. But keep in mind that these tests won’t replace every type of test. You still need other types of tests. But mostly, that’s a developer concern.

These acceptance tests are a great way of

• connecting developers and business people
• having requirements, tests and documentation in one central document
• eliminating waste that often accompanies analysis documents, analysts and manual testing (though it doesn’t replace them!)

In my experience, Gherkin-style tests are still severely underused in the IT sector. In part, this is because neither developers nor business people know them (well). If you’re interested in some more information on how you can automate your tests using Cucumber, let me know or have a look at the Cucumber site.