Acceptance tests!

Everything starts with a test…

Welcome to the world of test-driven development. Yay! I hadn’t given it too much thought before starting the course, tbh. But getting cracking on those user stories makes me understand the finesse with the initial ordeal I was struggling to wrap my head around. It’s the outside-in approach to implementing code. The essence to getting s**t done!

We write acceptance tests to prove/test interactions – do they yield the expected result?

Unit tests – spec tests, used for ‘seeing’ the database structure and testing it’s tables, their connections and respective validations.

We write acceptance tests for all of our features and use Cucumber and Gerkin as our testing framework for BDD, behaviour driven development.

Each feature then includes various scenarios that we can foresee.

For example, if we were to list a bunch of dishes on a site we’d write a feature story like this:

When I visit the site

Then I would like to see 'pizza'...

We then translate this to runnable step definitions and then we’re are able to run the test straight from the terminal. As we build up the tests they can be run all in one go or separately and for each feature. So as we develop, we expect the tests to initially fail and then turn green as we solve each corresponding implementation.