Today, my pair commented on how we have gotten a lot of use from our test-helper classes. How true, how true. Over the course of the last year, we have created the classes needed in by our application, and the tests to support those classes. But we didn't stop there. We also created many small utility classes to support our tests. These classes are barely worth writing, or so it would seem. They are actually priceless.
We have gotten a lot of re-use from these classes because they are small and concise. They each address and encapsulate one sole responsibility. The classes usually consist of two or three methods, and are no longer than about twenty lines. It's in this precision that they find their utility. Being small and to the point, it is very easy to pick the right class when needed.
We've developed classes to set and reset system properties; to set and reset logging levels; to read and write private fields; to set id's on our domain models; and many other small responsibilities. At first, when developing these helpers, we would wait for a duplicate need to appear, and then factor out a re-usable component. As we got better at this, we wouldn't wait for a duplicate need, but instead would factor out responsibilities as we saw them appear. This helped us get even more utility from these classes. As soon as the classes were created, uses for them would appear.
By encapsulating concepts, keeping concepts small and concise, and identifying concepts early, you will increase your chances for re-use, and get a lot of mileage from your classes.
My takeaways from this experience:
- encapsulate responsibilities
- create small classes
- factor responsibility early
No comments:
Post a Comment