Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

4 Answers

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).

share|improve this answer
    
but you can keep test coverage low. –  user1249 Jun 14 '12 at 17:13
4  
+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
2  
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 1:46
    
prototypes becoming production is so common, some invented the term "protoduction" for it codinghorror.com/blog/2012/07/new-programming-jargon.html –  Nate Parsons Aug 8 '12 at 3:59
add comment

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.

share|improve this answer
    
+1. See also 147055 –  faif Aug 8 '12 at 11:30
add comment

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.

share|improve this answer
1  
+1: I go faster with TDD, especially with unfamiliar technology where I'm unsure how things work. –  kevin cline Aug 7 '12 at 23:01
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.