From the course: iOS App Development: Test-Driven Development

Why test-driven development?

From the course: iOS App Development: Test-Driven Development

Start my 1-month free trial

Why test-driven development?

“

- If you're new to test-driven development, it might sound like a lot of work, and you may be asking yourself how you benefit from using it in your projects. To answer that question, we first need to take a look at some of the challenges of modern app design. The market has come to demand apps that offer a large set of features, complex usability, and customization. This level of complexity means that the code bases for these apps has grown significantly, unless you're working on a small, single-feature app. And testing them by hand has become inefficient and impractical. Along with the size of an application, human testing and QA requires the app interface. This adds a secondary step to testing, which automation can entirely eliminate. Lastly, because an interface is required, human testing time is exponentially greater than automated testing time. There are wonderful advantages to test-driven development, but there are also drawbacks that you need to be aware of going in. With any new endeavor, it's largely a game of pros and cons. So what exactly can we gain from implementing test-driven development into our applications from day one? First off, we get to know our feature sets intimately. By only writing code that is absolutely needed, we keep our features small, modular, and well-documented all in one shot. Adding to that, how much easier it is to maintain and refactor our code when we have great code coverage and how many fewer bugs we get later in development. We've got a wonderful new test system. For drawbacks, we mostly need to understand the nature of test-driven development. It can't be effectively implemented piecemeal. The entire development team and QA teams need to be on board and active. Naturally, since the tests are so tightly bound to the code we write, when features and such change, the tests need to change as well. Now the biggest disadvantage, however, is the time it takes to do all this. Writing tests for everything is time-consuming. There's no way around it. But I would personally almost count this as an advantage when you force yourself to slow down and think about good architecture, proper design pattern use, and cutting out the fat in your applications.

Contents