Last time I was writing about few tricks in creation of test fixtures. How to improve their maintainability in the long run and how to use some of the groovy’s DSL fatures to make them easier to use and read. Most of the techniques in the previous article were trying to wrap SUT in the invocations that are focused on the test context itself, without the need to go into every detail of SUT API. This time I want to focus more on enhancing the SUT itself, that will add to the readeability of the test, without compromising the design of the SUT.
Ok, so right out of the bath: this entry is not about writing good tests. It’s not about writing clean tests either. This topic has been tackled on both in the past (like in the famous Clean Code book) and even quite recently on many occasions. No, it’s about doing the one more step, when your tests are understandable and easy to read and follow. It’s about checking the “what if”, experimenting with the form and tools and trying out new things, or at least in a new context. Long story short, it’s about putting the Groovy DSLs capabilities to work for your tests. I don’t claim to exhaust the topic either, simply writing down what has been working for me so far.
subscribe via RSS