I’ve been playing with various ways that Kiwi can be used for testing code. It certainly has powerful capability for performing low level unit testing in a very organized way. I’ve been doing this using strictly OCUnit logic tests.
I don’t tend to use OCUnit application tests much, since they tend to be slower. And frankly, it didn’t even occur to me to try running Kiwi under application tests until last week. I ran into a situation where the code that I’ve been writing is 100% unit tested, and passing all tests, but the app doesn’t do what I want it to do.
Upon thinking about how this happened, I realized that my TDD focus has caused me to think at too low a level. I had skipped too quickly through the much needed high level design in order to quickly get to writing tests.
So I began thinking about how I could write higher level tests first, akin to acceptance tests, and use those to drive TDD at a lower level. This prompted me to think about whether Kiwi would run on Application tests, which I now know works.
So I’m heading down a direction where I’ll be using Kiwi in OCUnit application tests to define expected behavior (story acceptance tests), and then Kiwi in OCUnit logic tests to implement those behaviors via TDD. I’m exciting about this approach, and I’ll be updating this post going forward regarding how it is working.
What you describe here seems very similar to the Behaviour Driven Development (BDD, sorry for more acronyms!) philosophy. BDD says you should write high level application tests, make sure they fail, then drop down to lower level unit tests to test and implement the logic necessary for the higher level application tests to pass. It adds a cycle around regular TDD that makes sure low level unit tests are actually adding functionality to your software that results in the correct behaviour at the application level. Some info here: http://msdn.microsoft.com/en-us/magazine/gg490346.aspx (The second diagram demonstrates the extra BDD cycle.)
Interested to here your thoughts. I’ve found your posts very insightful and have really helped me to implement testing in my own iOS development.
Really good comment, thanks. I recently participated in a bug bash, working in some existing code that had full Kiwi test coverage. I was able to very quickly jump in and fix the code, and modify and add new tests. Kiwi really rocks!
I’m exploring now how to better organize Kiwi tests in order to provide the layered bdd/tdd approach you describe. It’s really great that Kiwi looks like it will work well for both.
My only reservation at this point with Kiwi is the apparent difficulty of debugging tests due to the use of blocks. I’m still looking for better ways to do this. Any suggestions?