Key FeaturesA practical guide to writing effective, organized, and clean code that works wellLearn test-driven principles to help you build better-designed apps with fewer bugsA comprehensive overview of the techniques available for TDD in SwiftBook DescriptionTest-driven development (TDD) is a proven way to find software bugs early. Writing tests before you code improves the structure and maintainability of your apps. Using TDD, in combination with Swift 4's improved syntax, means there is no longer any excuse for writing bad code.
This book will help you understand the process of TDD and how to apply it to your apps written in Swift.
Through practical, real-world examples, you'll learn how to implement TDD in context. You will begin with an overview of the TDD workflow and then delve into unit-testing concepts and code cycles.
You will also plan and structure your test-driven iOS app, and write tests to drive the development of view controllers and helper classes. Next, you'll learn how to write tests for network code and explore how the test-driven approach—in combination with stubs—helps you write network code even before the backend component is finished.
Finally, the book will guide you through the next steps to becoming a testing expert by discussing integration tests, Behavior Driven Development (BDD), open source testing frameworks, and UI Tests (introduced in Xcode 9).
What you will learnImplement TDD in Swift application developmentFind bugs before you enter code using the TDD approachUse TDD to build models, view controllers, and viewsTest network code with asynchronous tests and stubsWrite code that is a joy to read and maintainDevelop functional tests to ensure the app works as plannedAbout the AuthorDr. Dominik Hauser completed his PhD in physics from the University of Heidelberg. While working as a university professor, he started iOS development in his spare time. His first app on physics has been an astounding success worldwide. Since then, he has turned himself into a full-time iOS developer, with a number of successful apps to his name. He has been a Swift developer since day one and runs a blog on iOS development.
Table of ContentsYour First Unit TestsPlanning and Structuring Your Test Driven iOS AppA Test Driven Data ModelTest Driven View ControllersTesting Network CodePut It All TogetherCode Coverage And Continuous IntegrationWhere To Go From Here
Dr. Dominik Hauser completed his PhD in physics at Heidelberg University, Germany. While working as a teacher university, he started iOS development in his spare time. Since then, he's turned himself into a full-time iOS developer, crediting a number of successful apps to his name. He has been a Swift developer since day one and runs a blog on iOS development at https://dasdom.github.io.
3.5 This attempts to fill a gap that's existed for far too long – approachable documentation on how to get started with XCTest, particularly if new to TDD. But while I found it does do that, it's more a repetitive red-green-refactor drill than a deep or broad dive, intentionally omitting performance tests, multiple targets and validation cases entirely, with other concepts and entire areas only lightly addressed through single example. It's a reasonable introduction and there certainly are some valuable tips in here, yet I couldn't help but be struck by the fact that it's a 3rd edition, and an ebook, and still contains basic layout errors. The book perhaps best resembles the "write just enough simple code" approach of TDD itself. A worthy addition that I'd absolutely recommend for novices to the topic, but neither an XCTest/Xcode nor anywhere near a TDD reference-like work.
I have mixed feelings about this book. On the plus side, it was definitely a good introduction into the tools available on testing with iOS and Swift. I liked also the fact that the author guides the reader through an entire project and takes the time to TDD (almost) all features. At the same time, there are a few thing I wished while reading the book. For once, it would have been interesting to have a more thorough introduction to UI tests and the directives available in the library. But the biggest doubt I have is actually about the way the code was tested throughout the exercise. Very often I found the tests being very very coupled to the implementation, making tests and code very brittle; see for example the bug found while making the UI, the fix for which broke a few other unit tests. In an ideal situation I would expect this not to happen, and when it does I always ask myself if there isn’t a better way to abstract the test. I’m still giving the benefit of the doubt here because I’m not an iOS expert and I’m not sure if this is the canonical (or only) way to do things. Nevertheless I expected something of higher quality in this regard.