Test-Driven iOS Development (Developer's Library)
Language: English
Pages: 256
ISBN: 0321774183
Format: PDF / Kindle (mobi) / ePub
As iOS apps become increasingly complex and business-critical, iOS developers must ensure consistently superior code quality. This means adopting best practices for creating and testing iOS apps. Test-Driven Development (TDD) is one of the most powerful of these best practices. Test-Driven iOS Development is the first book 100% focused on helping you successfully implement TDD and unit testing in an iOS environment.
Long-time iOS/Mac developer Graham Lee helps you rapidly integrate TDD into your existing processes using Apple’s Xcode 4 and the OCUnit unit testing framework. He guides you through constructing an entire Objective-C iOS app in a test-driven manner, from initial specification to functional product. Lee also introduces powerful patterns for applying TDD in iOS development, and previews powerful automated testing capabilities that will soon arrive on the iOS platform. Coverage includes
- Understanding the purpose, benefits, and costs of unit testing in iOS environments
- Mastering the principles of TDD, and applying them in areas from app design to refactoring
- Writing usable, readable, and repeatable iOS unit tests
- Using OCUnit to set up your Xcode project for TDD
- Using domain analysis to identify the classes and interactions your app needs, and designing it accordingly
- Considering third-party tools for iOS unit testing
- Building networking code in a test-driven manner
- Automating testing of view controller code that interacts with users
- Designing to interfaces, not implementations
- Testing concurrent code that typically runs in the background
- Applying TDD to existing apps
- Preparing for Behavior Driven Development (BDD)
The only iOS-specific guide to TDD and unit testing, Test-Driven iOS Development covers both essential
concepts and practical implementation.
Software Requirements (3rd Edition)
Essential C# 4.0 (3rd Edition) (Microsoft .NET Development Series)
Programming C# 5.0: Building Windows 8, Web, and Desktop Applications for the .NET 4.5 Framework
Sustainable Infrastructure: The Guide to Green Engineering and Design
looking at what happens to the fahrenheitLabel property. Now is the time to make use of that capability. It would not be appropriate to just print out the result and expect the user to read through, checking that each line of output matches a list of successful results; that’s really inefficient and error prone. A key requirement for unit tests is Verifying the Results that they should be self-testing: Each test should discover whether its postconditions were met and report on whether it was a
provides a mock object for verifying that log messages match what you would expect, and has convenience categories for testing graphics and image code. Table 4.2 Test Assertion Macros Provided by GTM’s Unit Testing Capabilities Test Macro Success Criteria STAssertNoErr(expression, msg, ...) Expression is an OSStatus or OSErr equal to the constant noErr. STAssertErr(expression, err, msg, ...) Expression is an OSStatus or OSErr equal to the value of err. STAssertNotNULL(expression, msg,
course, with this book being about test-driven development, the app will be written in a test-first fashion.This chapter defines the application’s specification and sets out the strategy for developing the functionality. At the end of this part of the book, you’ll have a fully working—though by no means full-featured—app, supported by a suite of unit tests.You’ll also have seen how the tests help to design and implement the app code.The full project is available from https://github.com/iamleeg/
singleton, but that object offers no way to investigate its state. How can we tell that the notification was posted? One obvious way is to use the fact that if the object under test posts a notification, we can receive that notification in the test code.This means using a real, live NSNotificationCenter:The trade-off against creating a fake notification center is that the real notification center might introduce complications that stop tests being reliably repeatable, or make them very slow. On
work. Whenever you change the application, you should be able to run all the tests in a few seconds to ensure that you didn’t introduce a regression.You can even have the tests run automatically whenever you commit source code to your repository, by a continuous integration system as described in Chapter 4, “Tools for Testing.” Repeatable tests do not just warn you about regression bugs.They also provide a safety net when you want to edit the source code without any change in behavior— when you