Philosophy to write Objective-C unit test

Question

I am a really lost about it. I can study how write and run unit test in Objective-C with XCode, but I don't see how useful it is.

In resume, you have to write a method that will be called first to init all thing, and other to finish all things. In the middle you write the test. But it is like to run a normal program. You have access only in what you can have access, like I can't call private function or I didn't see how to do things like:

• If I enter function with X it have to give-me Y

I think it is because I have to fallow the "program rules". I can't see how test the interface things, (like the function one button will run when pressed).

How can I think about the unit test in Objective-C? What I can do and what I can't?

Answer 1

Rodrigo,

I think you may have a bit of confusion about unit tests and functional tests. Here's a short definition to work with:

• Unit test - exercises a single unit of application code. Does not invoke or use the application interface.
• functional test - exercises a function such as "Save", usually via the interface.

The unit test is there to check that when you call application code that processes data, it gives you the right answer.

For instance, say you have a routine that determines whether or not someone is entitled to a senior discount, given their date of birth. Your unit test would simply call that routine, and capture the output, and probably look something like this (pseudo-code)

Test CheckAge
    Result = IsSenior(DateOfBirth)
    If Result == ExpectedResult then PASS else FAIL

Somewhere your test would define expected correct and incorrect answers, and possibly create mock objects to mimic whatever framework your application is expecting to be available.

That's the quick and dirty explanation, which works for any language and framework. I expect others here will have much more information to offer.