A short introduction to automated testing - TDD / BDD

What is TDD / BDD?

This post is a continuation of the Project: Swift News, it will be better if you read all of the previous posts first. Click here to see the list of previous posts.

Building a complex application is not an easy task to do. Even working on a small project can be challenging. Tests are here to help. Tests can help you spot simple mistakes, but also give you confidence about your code and make refactor possible. Trying to write a testable code also force you to change and improve your app architecture.

What is TDD?


TDD stands for test driven development. In this approach you have to write test first. Which will of course fail as there is no implementation at this point, sometimes your code will not even compile as you don’t have classes that you are trying to use in that test. Then you have to write the code that will pass the test. Sounds simple?

Those steps are often called Red - Green - Refactor.

  • Red - you start with writing the test that will fail (red message says that test has been failed).
  • Green - write the code that will fulfill your test (green message says that test has been passed).
  • Refactor - this step is optional but you always want to do this, refactor your code to improve quality.

This is the TDD cycle, now you should repeat it until you have all of your functionality done and tested.

What is BDD?


BDD stands for Behavior-Driven Development. It’s similar to TDD in many aspects but the focus is in a different place. Sometimes you can read that BDD is a TDD done right😉 But it’s not about right or wrong, it’s yet another approach on testing. In BDD we are less interested in a state of an object and more interested in the behavior that takes place. You should think more of how an object should behave rather than how it should be implemented.

This all means that you should think of your tests from user story perspective rather than technical perspective.

BDD uses a special simple domain-specific language (DSL), English-like sentences that can help express the behavior. Example:

context("without action, first item should be selected") {
  it("active view controller should have title Latest news") {
    expect(sut.tabBarController.activeViewController?.title).to(equal("Latest news"))

In one sentence: you should test behaviors. Using BDD we will continue to use TDD cycle. Same principle as before, from red to green.

Test all the things!

Starting with testing is hard because this is a new concept. But there is a huge reward, instead of running the app over and over again you just run tests that use different input data and let your code to be tested within seconds. Write once, test many times.

What to test and how many tests should you write? The answer for this question is not straightforward, there is no silver bullet for testing. You should definitely try to cover the whole app, but more is not always better. Although the more tests you write the easier it gets. Just remember that you can’t have 100% test coverage 😉

On the next post we will write actual tests using Quick and Nimble. We will be testing our first module - Custom tab bar.