Using unit tests in IOS development

by Theo27. April 2012 21:57

Using unit tests in XCode you have the posibility to have two test targets (sub-projects) set up; one for logic tests and one for application tests. So whats the difference?

Logic tests run without the Application running, so you wont be able to reach your app-delegate or anything UI related, but you will be able to test POOC's (Plain Old Obj-C Classes). The Application Tests target, will start up the simulator and use it to run your unit tests.

When i develop, i normally use the logic tests target for the classes providing domain behaviour. Not having to start up the simulator makes theses tests fast to run, making the feedback cycle shorter and you always want as short a feedback cycle as you can get. So when implementing a new feature i start up with the base domain behaviour and make it run with the logic tests. I then i move to the GUI, which uses this new feature and implement it with tests in the Application tests target. With this working i can then wire up the nibs or similar and start up the simulator to check that the feature works as it should.

It did initially seem a bit odd to have two unit test targets, but being that the one needs the simulator to run it makes sense.

James Shore's - Lets Play TDD screencasts

by Theo7. June 2011 20:33

I recently discovered James Shore's most excellent "Lets Play TDD" series. It's a series of screencasts all of around 15 minuttes, which shows the building of a java application from the start with TDD - and this live, with all the choices and hick-ups and whatever included. 

I'm only just reached episode 22 so far, and he's made over a 100 at the time of writing this post. I will highly recommend this to anyone that wants to learn more about TDD in a real project.

As with Kent Becks TDD screencasts, its always great to see the different styles of TDD, i find it a great way to learn more. And James seems to almost produce episodes faster than i have time to watch them :).

First blog post about the series:http://jamesshore.com/Blog/Lets-Play/Lets-Play-Test-Driven-Development.html

Links to all the posts: http://jamesshore.com/Blog/Lets-Play/

..great stuff

Kent Beck TDD screencasts

by Theo15. February 2011 21:14

A good resource for anybody wanting to learn more about Test Driven Development, is the 4 screencasts by Kent Beck, which can be bought from The Pragmatic Bookshelf site.
http://pragprog.com/screencasts/v-kbtdd/test-driven-development

This is Kent Beck describing the workflow he uses when doing TDD and is a great way to learn a bit more about it.

Here’s Mark Needham’s comments of the screencasts:
http://www.markhneedham.com...kent-becks-test-driven-development-screencasts/

Interesting points to notice about the approach

  • He starts of writing the code inside the test, and first pulls it out into its own class when its justified to do so. This way its easier to start, as we don’t have to find out how we want the design of the class/classes, before we have the code to put in there.
  • Smaller tests are removed, when bigger tests cover the same parts. As tests must be maintained, it makes sense not to have multiple test covering the same areas.
  • Kent tries to Call hits shots, when running the unit tests, meaning that he tries to predict if the test is going to evaluate to red or green, as a exercise when TDD’ing.

Using unit-tests to shorten the feedback cycle

by Theo14. November 2010 20:30

The speed of development can be measured in how long it takes to write code, and then how long it takes to test that it works.

Now the normal way of testing is running the system and poke around in the area of the change, to confirm that the change works as it should. This can be very slow if you have to enter multiple hierarchy's  of nested pages or because the system simply takes a while to load and enter. This is where unit tests can be of help.

Even though you don’t buy into the whole idea of covering everything with unit-tests, shortening the feedback cycle will shorten the time i takes to find out if your change works as it should, and this can be helped by testing through a unit-test instead of though the actual system.

I experienced this my self, when building a component that would allow other systems to integrate data our. In this case every request needed to convert input data, validate it, run validation against another external source (returned as json), and then save in the database. Now in this case, i found that creating simple unit tests, for testing the parts allowed me to build this more in component, and much faster, as i was shortening the feedback cycle. Now not every piece of code is straight forward to unit test. But at least evaluating the quickest/easiest way to test a piece of code, should be on every pragmatic programmers backbone.

A very basic unit test

by Theo23. June 2010 19:33

Today i realized what the most basic form of a unit-test is.

It's this:

// If the account's type is normal,
// the account must be reapproved
if(Account.Type == AccountType.Normal)
{
Account.ApprovalExpiryDate = DateTime.Now;
}

I was looking at a similar piece of code on the project i'm currently developer on at work, and was wondering why the first line of comments were there (i hate unnecessary comments, which clutter the meaning of the code). And then i realized that even though the first line of comments is clearly repeating whats really easily read in the expression in the if statement, it is making sure that that's what should be in the if-expression. If someone were to change the expression we would still have that line of code to make sure that the expression was what was originally intended.

Normally i wouldn't write the first line of comments, but only the second as it describes why we set the accounts ApprovalExpiryDate to the current DateTime, which isn't very clear. Even better would though be to extract the line in the if into a method that expressed what we try to explain in that comment line (SetAccountToBeReapproved() or something).

Now this is a stupid example yes, but the testing mindset is there. The best solution, and next step would then be to have a unit test check this, and enforce it automatically instead .

Theo Andersen

Hi, you've reached my blog on software development.

I use this blog mostly for my own purpose of remembering stuff, so i only put things here once in a while when i get the time.

My current focus is on TDD, unit testing, object oriented code and IOS development.