4

I'm developing an iOS app, which is a prototype for a customer. They're expecting it to not be of production standard and are happy for a few rough edges here and there.

Since this is my first commercial venture into iOS / Objective C (I'm an android developer that is trying to cross-train into iOS), my primary focus has been learning the Objective C language and how to develop the app, and I have not invested any time into learning how TDD can be applied in this environment.

My question is, even for prototypes, should you still try to apply TDD and create unit tests?

user155695
  • 313
  • 2
  • 7

5 Answers5

12

The "correct" answer is yes. TDD should be considered "best practice" wherever the tools for TDD are available either in the language or in the framework. Even if they aren't available in a form you may be used to with Java or .NET, you can create a simple program that consists of calling each of the unit test methods one at a time, catching thrown exceptions (which indicate a test failure).

The reason why is that cheap, inexpensive little in-house prototype apps, built as proof-of-concepts or for training/demo/personal use purposes, become production apps all the time. Just as an example, I had at one point a job duty to create bootable flash drives for our field techs, containing system tools and OS images. After doing it manually the first time for a batch of 50, I created a simple app, ThumbPrinter (being clever), that automated a large portion of the script-running and batch-tracking, and all I had to do was tell it how many thumb drives I wanted made, where the data to put on them was, and which drive letters would be used during the batch, and then handle the plugging in and unplugging of flash drives as it went.

That app is now used by others in my department and I'm constantly called on to "fix" things that were never a problem when I just used the program myself, because unlike in a production environment, I knew how I'd use it and never considered using it in any different way, and I also knew the causes of certain glitches and how to avoid them because that was easier than making the code work right. If I'd known the app would be used by anyone else I'd probably have taken more care building it, up to and including TDDing it.

Now, that being said, TDD is not necessarily the end-all be-all of proper software development. We got along for 3-plus decades before it was ever proposed, and people still write correct code without unit tests. So, it's really up to you; you'll have to find out just how easy it will or won't be to write and run unit tests for an iOS app, and whether that cost of time and effort is worth the advantages of TDD (regression prevention, YAGNI adherence, definition of "done" and automated proof of correctness).

KeithS
  • 21,994
  • 6
  • 52
  • 79
  • but you can keep test _coverage_ low. –  Jun 14 '12 at 17:13
  • 6
    +1 on the "prototype becomes production", I'm very much expecting them to say "Looks great, lets stick it on the app store"... – user155695 Jun 14 '12 at 17:15
  • 4
    Another +1 for "prototype becomes production". I've been there several times. – tdammers Jun 14 '12 at 17:32
  • "We got along for 3-plus decades before it was ever proposed" – Actually, Kent Beck says that he *did not* invent TDD, he read about it in an article from the 1960s and then only described it. So, it's only 1 decade ;-) – Jörg W Mittag Jun 15 '12 at 01:46
  • prototypes becoming production is so common, some invented the term "protoduction" for it http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html – Nate Parsons Aug 08 '12 at 03:59
8

Kent Beck would say no, but based on other things he's written I would say that the caveat there is that you need to throw away that code. If you aren't the person who decides what to do with your code, then you should probably write tests all the time.

Mike Burton
  • 181
  • 4
  • +1. See also [147055](http://programmers.stackexchange.com/questions/147055/when-is-unit-testing-inappropriate-or-unnecessary/) – sakisk Aug 08 '12 at 11:30
4

A prototype's scope should touch some key features which are implemented in a correct way. Since you will be demoing the prototype, having these features well tested seems to me to be a good idea.

But of primary concern is whether you believe TDD will actually accelerate your development. It is my opinion that having a high develop-test cycle frequency driven by TDD will accelerate any project, regardless of size or scope. Perhaps projects with a limited scope will actually benefit more, since it is easier to write tests for them.

Dibbeke
  • 2,514
  • 1
  • 16
  • 13
4

If you use TDD, then yes, you should use it even for prototypes. There's a couple of reasons for this:

First off, testing small bits of your code makes it easier (as always) to get the whole thing right. When you are just learning the language you are more likely to make crazy mistakes, and working with smaller pieces of code helps.

Second, prototypes have a way of mutating into production apps like you wouldn't believe. It'll be a lot easier to do that if you've already got a body of test code.

Downsides are that you not only have to figure out how to write an iOS app, you ALSO have to figure out how to write test code for an iOS app, which is two problems instead of just one. But remember that having all those tests is going to be a boon down the line when you're asked to turn the thing into the real deal on the double-quick.

Michael Kohne
  • 10,038
  • 1
  • 36
  • 45
1

Personally I do TDD whenever I'm on contract or write code for someone. When I build a prototype for myself and I'm uncertain about its future then I try to move forward as fast as possible and usually do not do TDD. However, I pay attention that the code I write is 100% testable and does not have to be refactored if the prototype should turn out to have potential then I usually write the missing tests and continue with TDD

Martin Nowosad
  • 109
  • 4