- What Is Software Testing For?
- Who Should Test Software?
- When Should Software Be Tested?
- Examples of Testing Practices
- Where Does Unit Testing Fit In?
- What Does This Mean for iOS Developers?
What Does This Mean for iOS Developers?
The main advantage that unit testing brings to developers of iOS apps is that a lot of benefit can be reaped for little cost. Because many of the hundreds of thousands of apps in the App Store are produced by micro-ISVs, anything that can improve the quality of an app without requiring much investment is a good thing. The tools needed to add unit tests to an iOS development project are free. In fact, as described in Chapter 4, the core functionality is available in the iOS SDK package. You can write and run the tests yourself, meaning that you do not need to hire a QA specialist to start getting useful results from unit testing.
Running tests takes very little time, so the only significant cost in adopting unit testing is the time it takes you to design and write the test cases. In return for this cost, you get an increased understanding of what your code should do while you are writing the code. This understanding helps you to avoid writing bugs in the first place, reducing the uncertainty in your project’s completion time because there should be fewer show-stoppers found by your beta testers.
Remember that as an iOS app developer, you are not in control of your application’s release to your customers: Apple is. If a serious bug makes it all the way into a release of your app, after you have fixed the bug you have to wait for Apple to approve the update (assuming they do) before it makes its way into the App Store and your customers’ phones and iPads. This alone should be worth the cost of adopting a new testing procedure. Releasing buggy software is bad enough; being in a position where you can’t rapidly get a fix out is disastrous.
You will find that as you get more comfortable with test-driven development—writing the tests and the code together—you get faster at writing code because thinking about the code’s design and the conditions it will need to cope with become second nature. You will soon find that writing test-driven code, including its tests, takes the same time that writing the code alone used to take, but with the advantage that you are more confident about its behavior. The next chapter will introduce you to the concepts behind test-driven development: concepts that will be used throughout the rest of the book.