Test driven development

Discussion in 'iOS Programming' started by nashyo, Jan 28, 2013.

  1. macrumors 6502


    Oct 1, 2010
    What is everyone's opinion on test driven development in an iOS environment?

    I have looked over unit testing and done some simple implementation using a test target.

    I don't fully understand it.

    One example of unit testing I read about involved examining the structure of incoming data, to ensure it was structured as expected. But why? Why not put in-place a conditional statement that captures a null object if one is returned? It seems like a lot of excess code.
  2. macrumors regular

    Mar 5, 2006
    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.
  3. macrumors 68030


    Sep 2, 2008
    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.
  4. thread starter macrumors 6502


    Oct 1, 2010
    I like the idea of test driven development. It makes a lot of sense. If it might appear in upcoming jobs then it might be worth learning.

    I'm surprised there are not that many responses to this. I thought it would be a popular thread. I guess there aren't that many people doing this.
  5. macrumors 6502

    Jun 17, 2007
    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!
  6. thread starter macrumors 6502


    Oct 1, 2010
    So Amorya, you had some code that confirmed how many objects were in several arrays you had for several sections of your table view?

    You compared these values against how many objects you wanted the arrays to have in the first place?

    Did you provide a hard coded value for that check? Such as, "7" objects should be in array 'X' ?

    Forgive me for asking you to spell this out. I'm asking because I'm still having a hard time seeing the point.
  7. macrumors 604


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


    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.

Share This Page