Karmacrash

How I Test... A History of Learning

- May 6th, 2008 18:43

I became interested in test driven development after reading an interview with Alan Cooper in which he remarked that the then still nascent (2001?) movement of both agile and test driven development represented something new and interesting in the world of software development. Thus began my long standing curiosity about what was so new and interesting about things such as extreme programming, scrum, and their contrast against waterfall. I initially began TDD with NUnit during the time when I was a .NET developer. I remember those days as being a struggle to learn what TDD really was amongst wrestling with the technical complexities of configuring NUnit to work with web apps. For a .NET web application I was able to test the business layer of my app but when it came to the views and html levels, there was a lot of work involved to get testing on that level and at the time I didn’t have a strong enough grasp on it to be able to do it comfortably.

Then I discovered RubyonRails and within an afternoon found not only a framework that gracefully solved the problems I wrestled with in .NET as far as MVC separation and freedom from a compiler, but also unit testing was baked right into the framework and it was easy to use. Having a strong conviction that TDD would make me a better developer I resolved not to write any ruby code without testing first, and it’s a conviction that I carry with me to this day. Finally, I was able to use TDD on a whole application and see how it supported the entire life cycle of the application from development to maintenance.

I started out as a devotee of Test Unit, I wrote code that checked final states and I used fixtures to simulate test conditions. Enter in my first testing pains. My tests were riddled with dependencies where making a change to one my models would cause breakage among a whole host of tests in both my unit tests and my functional tests. Fixtures were driving me insane in much the same way and I felt like I spent more time maintaining my fixtures than I did my code.

Then along comes Rspec and the pendulum swings in the other direction. Okay so to this day I really don’t see the distinction between TDD and BDD, to me it still feels like the same thing and the distinction in testing semantics is a bit lost on me. I don’t see Rspec as being a dramatically different testing paradigm than Test Unit but rather it provides conveniences that address some of the problems discovered with classic unit testing. What changed most for me was the adoption of mocks and stubs. Mock objects were something that I had a hard time learning until I discovered Rspec and it’s mockist way of doing things. So I did what most developers do when given a new shiny toy, I way over did it. I mocked and stubbed the shit out of everything, I had some amazing 10 line stubs on multiple objects and the nightmare of maintenance that went along with them. I finally freed myself of dependent tests by isolating my controller and model layers, my specs ran much faster than fixture laden tests and I now had a new set headaches in the form of brittle tests that were caused by way to much implementation mocking.

This is the background of how I got to where I am today. I’m reevaluating my whole approach to testing, I know the right way for me to test is going to be created by me. In in a quest to find the method of testing that gives me better design for my classes, visibility into the state of my application, speed of execution, and least amount of grief. Testing is complicated there is a time for state based testing and there is a time for interaction based testing. You have to pick your poison carefully. I’m going to develop a system that works for me and I have the advantage of having written a lot of tests in my time, in the back of my head though I want to create a system that is simple enough to teach to others. I’m going to find a way…