More TDD
Two weeks ago I wrote about my first experiences with iOS Test Driven Development. Since then I’ve continued using TDD, tried new testing frameworks and have fully committed myself to the process. I’m still not testing everything but hope to expand my testing over the next few weeks.
Kiwi
I’ve started using Kiwi as my testing platform. Kiwi is designed for Behavior Driven Development but is also suitable for TDD. I started using it for its improved partial mocking and stubbing of class methods. As Ive used it I’ve found it much more natural to work with and I like its description / context blocks for test organization. I plan to use Kiwi going forward.
Speed
In the last article I mentioned that my development speed was slowed somewhat while I was learning the new tools. For the first part of the last two weeks I had to restart the learning curve with Kiwi but have been able to grasp it pretty quickly. Over the last week I’ve felt my development speed improving and the confidence I get from having a thorough test suite has allowed me to refactor my code until its simpler, cleaner and easier to work with. This clean up has allowed me to work with my own code more efficiently.
I still feel that TDD is helping me keep focused on the work and I’ve been quite productive over the last two weeks.
Rails
I’ve also started learning Ruby on Rails as I often need to design websites used to administer the backend datasets for the apps I develop. I’ve been following the excellent railstutorial. The tutorial also follows the TDD paradigm and has helped to reenforce what I’ve been learning with my Cocoa Touch development.
Working Without Tests
Over the last two weeks I’ve primarily been working with new client project, code named ProjectF, that with which I began my TDD adventure and with rails tutorial. But, I’ve also done a little work on Prison Pushups. I’ll also be starting up again with my client’s older project, codenamed ProjectQ, over the next few weeks. Neither of these two projects were developed with TDD and as such have no tests.
While working on Prison Pushups I really missed having a test suite. I needed to move some code around and had no automated test suite to confirm the changes I made. Sure, I was able to get through the changes but unit tests would have been very helpful. I feel like really embracing the TDD workflow, but it is making working on my older projects more difficult.
I’ll be starting on my client’s older app again this week and it also doesn’t have unit tests. I believe I will start adding tests to the projects. This will be a good experience for me to learn how to add tests to an existing project. And, it will allow me to do some refactoring to the app that it sorely needs. As I mentioned in my last post on iOS Model Design, ProjectQ has too much business logic in its controllers. I’d love to break up these unwieldily objects as I continue its development but without tests I risk breaking essential interfaces and functionality.
I even miss tests in ProjectF as I haven’t been diligent in writing tests for all of the controllers. And over the last week I found a need to extract a super class from one of my controllers so as to share some of the functionality with another controller. While this was straightforward I would have preferred working with units tests to confirm the changes.
Next Steps
I plan to continue housing TDD with ProjectF and adding tests to ProjectQ. I’d like to continue to develop my TDD skills.