Test Driven iOS Development: BrowseOverflow as a Code Kata
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
My goal in writing Test-Driven iOS Development was to take readers from not knowing how to write a test for their iOS apps to understanding the test-driven development workflow and how it could work for them. That mirrored the journey that I had taken in learning about test-driven development and that had led me to wanting to write a book to share what I'd learned with my peers.
This has an interesting effect on the structure of the book. Not all of the sample code from the BrowseOverflow is shown (although it's all available on GitHub). This isn't an accident we made in the editorial process. It's a feature: for any test shown in the book, there are numerous different ways you could write application code that would all be just as good. Anything that causes the test to pass, and doesn't make the other tests fail, is fine. As you work through the book and gain more experience with test-driven code, I've left you more freedom to try working with the code and filling in the details for yourself.
Just as the many-worlds model in quantum theory says that there are many branches of the universe that are created every time a decision is made, so there is a "many-BrowseOverflows" model of test-driven iOS development. Every time a test is written, there are many different solutions to passing the test, leading to there being multiple potential BrowseOverflows. The code that you see on GitHub is just one possible BrowseOverflow, but any other code that satisfies the same tests is one of the other possible BrowseOverflows.
This means you can treat the book like a kata: the Japanese martial art technique of improving a practice by repeating it over and over. The first time you read Test-Driven iOS Development, you can choose to follow the example code very closely. Where the code isn't given in the book, you might choose to look at the source code to understand how I solved the problems posed by the tests. But the end of the book is not the end of the journey: you can go back, taking the tests but implementing all of the app code yourself. You can do this as many times as you want, trying to find new ways to write code that produces a BrowseOverflow app.
Finally, when you're more confident with the red-green-refactor way of working, you can write a BrowseOverflow app that's entirely your own creation. You can define what the app should do, create tests that express those requirements, and write the code to implement it however you like. This is a great way to test out new ways of working, for example different test frameworks like GHUnit or CATCH. It also lets you try out different ways of writing the application code: you could write the same app but trying to use more blocks, or try to use the smallest number of properties in any class, or any other challenge you want to set yourself. Because you know what the software should be capable of, you're free to focus on whatever skill you're trying to exercise.