Being a new user to DevCreek, I decided to perform an experiment and see how the tool helps/hinders me with my normal development work. The task at hand was to enhance existing functionality in the back end of a web application. I wanted to try and use the Testing Coach to see if I can recognize patterns or habits as I progress through the day. The first thing on my agenda was to put the DevCreek view in a prominent place within my Eclipse real estate. I placed it in the lower left corner where my Outline view usually resides.
Having DevCreek stare at me and supposedly “coaching”, I felt compelled to refactor before I made any enhancements. Things went fine, I broke some existing tests and fixed them again. The Testing Coach showed a neat little bar graph with small amounts of red and green bars and I was happy with the results.
Next came the enhancement work and a different turn in my perception of the Testing Coach. I was making changes to domain objects, data access objects (DAO), services, and presentation logic. I kept my changes relatively small. The domain objects did not have any behavior so no testing was involved. The data access object changes were straight forward and the unit tests were quick and simple to modify.
The pain began when I started modifying services and the unit tests for those services. I was not having a lot of luck fixing and modifying existing tests. The fact that junit was giving me a red bar and also having the Testing Coach give me a red as well made it very frustrating. There were 2 red bars staring at me. The longer this went on, the higher the frustration level, partly due to the fact that the Testing Coach was a time based measurement. The red bar in Testing Coach meant that I had been unsuccessfully doing my changes for a long time. Our service tests made extensive use of JMock to mock collaborator objects. The collaborators included DAO as well as other services. JMock test failures can be hard to trace.
So in retrospect, I think that the Testing Coach can be used as an indication that:
- I needed help and a second pair of eyes and brain on the subject (I admit I wasn’t pairing).
- Tests that cause such pain for an extensive period of time should be refactored to eliminate further pain.
- Expectations in mock objects should be kept to a reasonable level. Otherwise, they increase the cost of change and that’s not good.