While I was coaching a few teams last summer I realized that my perspective on testing Java applications changed because of Ruby. I used to be one of those people who would not to use databases when writing automated "unit" tests. I would then advise others to use test spies instead of the actual database dependent code. That works when you are working with code that interacts with a repository but what about when you test the repository itself? Well you all know how that ends up.
When I started to work with Ruby I started to apply the same mechanics that I used while working on Java projects, however I quickly discovered that my prejudice from working with other tools was an impediment to my success. Tests where fast and the tools where simple in spite of the fact that they dependend on external sources.
After working with Ruby, I returned to Java questioning my assumptions about testing. At first I started by writing component level tests that would execute the entire stack because I thought that Rails like functional tests would make sense in my Java world. The good thing that happened there was I discovered a rats nest of performance problems in our production code and it got my XP team thinking about how much we really ignored the P in Right BICEP. However, the tests were slow and after profiling them it was clear there was very little we could do to improve the performance. All of the resources in the tests were exhausted in bootsrapping, Spring contexts, Hibernate SessionFactory, etc...
Our team then went on to talk about what was going on. Turns out that the tests where telling us there was something wrong with the design, we just were not listening to them. What happened to "Tell, Don't Ask"? Why did my code suffer from so many smells?
Just around this time I discovered that Nat Pryce and Steve Freeman where writing their book on Growing OO Software Guided by Tests. Reading this helped me go through sort of an OO design revival and return to a tabula rasa.
I strongly believe that learning and working with Ruby has opened new doors for me both as a tester and designer. It has forced me to challenge what I thought was good code and now more than ever I realize how TDD is an art form that is difficult to master. It isn't some mechanical exercise that you can teach someone easily. It is a discipline that takes practice, time, and above all support from a good team.
1 comment:
Here are a few practical Smells courtesy of Naresh Jain
http://blogs.agilefaqs.com/2009/02/01/smells-in-test-that-indicate-design-problems/
Post a Comment