danilNil/TyphoonWithKiwi — pull request #1 by modocache (2014-04-18 21:36:58+00:00)
Title: Some suggestions for more behavioral tests.

I left the majority of comments in the files themselves. But they're only half the story.

When I think of behavioral tests, I think of tests that **specify** how my app is supposed to **behave**. "When I tap this button, it logs me in", for example. Nothing fancy--the specification is that "tapping the button logs me in", not that "sending the `-onLogin:` message to the view controller sends another message to its API service object". So my ideal test would *actually* tap the button (in this case by sending the `-sendActionsForControlEvents:` message to that button).

The "logs me in" part is trickier, since my server might be down, or I might be running my tests in a cave with no internet connection. If I actually had my app attempt to log me in with a server online, the tests would fail some of the time but not others, even though the code itself doesn't change. But that would be a bad test. Good tests, after all, pass or fail deterministically.

Luckily, we can stub the app-server interaction with [Nocilla](https://github.com/luisobo/Nocilla) (super awesome) or [OHHTTPStubs](https://github.com/AliSoftware/OHHTTPStubs) (not as awesome, but still good). These intercept requests to the Internet and return canned responses.

Now, ideally, all the code that calls out to the Internet would be contained within an API client class, and the tests for that class would use Nocilla. The view controller could then simply make an expectation that the API client is sent a `-loginWithUsername:password:completion:` message.

Anyway, that's my two cents.