iOS Test driven development

The word test in test driven development can cause confusion. It implies that test driven development is a replacement for running your app and checking that everything works. Test driven development isn't a replacement for testing that your app works.

You can think of test driven development as a way of designing your app's code. Instead of writing code for your app first, you start by writing a test that describes how your app code should behave. Then you write the code to make the test pass. A single test should test one thing, which means an app that uses test driven development ends up with a lot of tests.

As you noted, test driven development requires additional code to write the tests. But test driven development provides the following benefits:

• It forces you to think about what your code is supposed to accomplish before you write the code.
• It provides a strong incentive to write code that is simple to test, which usually results in simpler code.
• It makes your code easier to modify. If you change your code, you have a suite of tests to make sure your changes don't break anything.
• You spend less time debugging. Instead of stepping through your code in the debugger to find the problem in your code, the unit tests tell you there's a problem when they fail.

Regarding your question about the unit testing example, there can be problems with the incoming data besides a null object. The data could be in the wrong order. Some of the data could be invalid. Just checking for a null object isn't enough to ensure the code works correctly. Unit testing can help you find those problems, but you can write code to find those problems without using test-driven development.

Unit tests and Unit test frameworks and TDD are all related but different.

I think that unit testing isn't widely used among iOS developers. It's rarely brought up in any of the iOS developer forums that I frequent. There's no good code coverage tool for iOS.

I believe it is widely used among Java developers.

Unit tests and TDD aren't that useful in UI code. I've found unit tests or unit test frameworks to be more useful in model layer code.

Unit testing and other kinds of automated testing are part of modern disciplined development methodologies. If you want to get a job doing iOS development it will come up.

Test driven development is where you write a test before you write each bit of code, in order to make concrete your assumptions. The test tells you when you've correctly written the code. And since all the previous tests you've written are still there, you know at once if you violate any of those assumptions.

I find if your app has huge view controller subclasses where all the logic happens, TDD is hard and not that helpful. But the more you split up your code to work in smaller reusable units, the more useful it is.

For example, I have a library for rendering table views based on keypaths on a data model. Recently, I wanted to make it able to render multiple rows per object in the model, where previously it had only rendered one. That required quite a lot of complicated arithmetic inside the library, to get the index paths right. I wrote some tests first of all, giving each one a hard-coded model and testing that my library was outputting the correct number of table rows and getting them in the right place. Of course, at that point it wasn't, since I hadn't written the feature. Then I wrote it, and as soon as the tests showed up green I knew it worked… even though I hadn't used it in an app yet!

I just wanted to point out that there are frameworks available for performing unit testing on your UI:

http://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/UsingtheAutomationInstrument/UsingtheAutomationInstrument.html#//apple_ref/doc/uid/TP40004652-CH20

I've been reading up on test driven development a lot recently and it all seems like a great idea... But I'm not sure if these UIA tests can be set to run automatically at each build... My understanding is you can do that when using model / controller test frameworks.