User Stories

The expected behaviour of an application is first specified through user-stories which are written down in the form of features, scenarios and specific steps. An example story could go like this:

When I go to the list of all customers in our application and select all customers, then I want to be able to export this list as a PDF file.

Once at the beginning of every iteration in an agile development cycle, we translate our customers' needs into somewhat more detailed descriptions of features, scenarios and concrete steps written in the Gherkin syntax, a Business Readable — Domain Specific Language. We then make software called Behat & Protractor analyze those plain english specifications, and with the help of small bits of programs, they actually check that what's written in the user story actually holds true.

Code that we write needs to implement the required features — pass those automated tests — before it can be deployed. Not only does that help us in seeing what features still require our attention, it also allows our customers to verify that all of the features they requested have been correctly implemented. The other advantage of doing this is that every time our customers ask us to do a change on their application, we can do so without fearing a break in another, unrelated part of the application.

What it looks like

Because we take automated testing very seriously, we've even applied that methodology to our own website. The automated test for the page you're currently surfing goes like this:

            Scenario Outline: Navigating to the TDD page
                Given I am on the homepage
                When I follow "Test Driven Development"
                Then I should see "<heading>"
                And the response status code should be 200

            Examples:
                | heading |
                | Test Driven Development (TDD) |
                | Specifications |
                | What it looks like |
                | Unit tests |
                | Continuous Integration |
        

Unit tests

Tests mentioned above are useful to ensure that the code TenTwentyFour¹⁰²⁴ writes is actually conform to what our customers expressed. That's a good start. However, that in itself does not guarantee a bug-free application. In fact, nothing actually does. But we can at least try to get there with another trick we have up our sleeves which is called unit testing.

With the help of tools such as PHPUnit (for, you guessed it, PHP) or Jasmine (for Javascript), we make sure that the parts that users don't see do work too. We take components of the application, named "units", apart, and try to see if they behave as expected. Those are another kind of automated tests that we write before shipping application.

You can read more about unit tests here.

Continuous Integration

Since running all automated tests manually after each and every modification to an application's source code would be a tedious task for a mere mortal, TenTwentyFour¹⁰²⁴ uses Jenkins CI to automate both the testing and - should all tests succeed – deployment of the application's source code. Every time one of our developers commits new or modified code, Jenkins gets triggered and runs a series of tests. This is the only way we allow ourselves to ship code to our customers.