I enjoyed reading this book, It contains good information regarding testings and the explanation on how he built the app was rather good, However I don't think that an app as big as the one built in this book would require all these tests, I think that 182 Tests are way to much for such an app.

All in all i recommend reading this book if you are an App developer.

Bellow are my notes.

About Software Testing and Unit Testing

  • Unit tests are miniature Integration Tests
  • Good test is good documentation.
  • Writing tests for existing code is hard.
  • XP Test infected mindset; is thinking about how to test this instead of how to debug this.
  • TDD it helps create API that is simpler and easier to use.
  • TDD helps in creating Decouple Cohesive classes.

Techniques for TDD

Red, Green, Refactor

  • Red: Write a failing test that describes and encapsulate the desired behaviour and feature/function.

  • Green: Add classes or functions to make the test pass. Code should be just barely good enough.

  • Refactor: Adjust the written code without affecting the app behaviour. Remove code smells that you find.

TDD System Architecture

TDD uses extreme programming "System metaphor" as a way to describe the system architecture.

System metaphor is a way to describe a system to new people without throwing big documents on them. The description should be understandable even to non technical people.

For example:

  • "chameleon" is a metaphor for a "window that changes transparency"
  • Virtual clinic is a metaphor for an app that helps user book a Dr appointment.

Benefits:

  • Helps figuring out the overall design of the program.
  • Helps the team find a common vocabulary.
  • Its used in conversations with each other.
  • Its used in conversations with customers.
  • Helps everyone reach agreement about the requirements.

Ya Ain’t Gonna Need It (YAGNI)

You never write code that you don't need. even if you may expect the app to change don't write the code right now

Only write code that make a test pass.

How to Write a Unit Test

Steps

  1. Understanding the system requirement.
  2. Write the test, use mock objects
  3. Verify the test works by using assertion.

Notes:

  • Unit tests should be self-testing
  • Each test tests 1 condition.
  • Tests should be atomic.

Tools for Testing

OCUnit
  • Port of SUnit
  • Has fixture with teardown and setup.
OCMock
  • Mock objects are used to test side effects that a method could have on the system.
  • Mock object use stubbing to return a specific value when a method is called.
  • Mock object could set expectation for certain methods to be called. in verification the mock object checks that the method was actually called.
Continuos integration

Processes that watch your code, when a change is committed the checkout the change and run the tests.

Domain Analysis

Domain Analysis it is a method to analyse the business domain to produce Domain Objects.

In this analysis:

  • Nouns represent objects or properties in objects.
  • Verbs represent methods performed on objects.

TDD Tips

Design to Interfaces and not to Implementation

Always design your object interaction based on an Interface (Protocol) rather than on an Implementation, this will help you swich the implementation whenever you want.

Tell don't ask.

Always tell your objects what to use instead of having them ask what to use.
Telling mean that you should have a way of setting the Instance Variables of a class. Asking is letting the object decide on its own such as [NSFileManager defaultManager]

By telling the object what to use you are able to switch the object when testing (Dependency Injection). Alternatively you could create a Plugin Class that would decide which object to create.

Exposing private instance variables of a class

When you want to expose a private ivar you could do the following:

  • Extend the class and create a new method that expose that iVar.
  • Create a stub object for that class and attach a dynamic method that return that iVar.
  • Use key value coding to inspect the value of that iVar

Stubbing the network

  • Create a Mock class for the network, then using Dependency injection (Plugin pattern), inject this class instead of the actual Network library.
  • Use NSURLConnectionProtocol to return stubbed data instead of actual network calls.

What to not Test

  • Don't test The network, always stub the network out
  • Don't test Databases
  • Don't test the UI, Xibs and Storyboards
  • Don't test already tested code

Applying TDD to an Existing project.

Start by adding some tests around things that you are going to change:
- If you are fixing a bug, add a test that reproduce the bug. - If you want to implement a new feature, add a test that describes it.