Tests can create a feeling of being trapped, a burden that gets heavier to carry with every new test introduced. Building a stable, non-intrusive and quality ensuring suite of tests is a difficult task… but *why* does these problems surface?
Most people can agree that testing, performed in one way or another, for any type of product, is a great way for revealing quality and potentially later increase it. But the testing process can get problematic when you specify a static suite of tests and then continuously re-execute it through the lifecycle of the product, i.e. regression testing.
Stop and think for a second… what value does interfaces and abstractions provide to clients? They provide a way to enjoy a *particularly* valuable service without having to worry about the complex internal details of *how* it is provided to us.
Interfaces are not unique to software development, they are everywhere in our everyday community. Consider leaving your Toyota in for repair. Employer Mike is excellent fixing Toyota cars using custom-made tools. But do you, as a client, really care *how* and by *whom* the car was repaired, if you can observe that malfunctioning parts have been replaced and the car works better than before?
Mike will do his job better without being bothered by people who cannot keep up with his bleeding-edge techniques. Mike may quit or learn even better methods, throwing some of his old custom-made tools away. It is better to assure that the company service, as a whole, can deliver high quality for a wide array of diverse problems and clients.
This is a simplification, but you get the point.
I have observed that testing efforts (far too often) tries to verify unspecified implementation details, without really thinking of the consequences. Having too many poorly specified tests can easily snowball into a chaotic maintenance nightmare, making future product development difficult and unproductive. When these symptoms come creeping developers stop making continuous improvements, to avoid problematic refactoring and infectious conflicts with QA, hurting product quality more than helping it.
Internal domain experts can help you understand fundamental business strategies and what *really* matters for the company to be successful. Think long and hard when specifying significant interfaces that are visible for *both* internal and external business processes. Distill abstractions that capture high-level goals and concepts, not complex implementation details. Focus your design and testing efforts on these interfaces and you will earn stability.
Remember that business is fiercely competitive and vibrant, changing rapidly to outrun competitors. Allow flexibility for business to grow and evolve when defining interfaces and tests in your architecture. Enable interfaces to be combined into unique service compositions to support unforeseen business capabilities, maximizing value with minimal efforts.
The future will forever remain untold so do not make too many assumptions on what tomorrow brings.
There is no such thing as a crystal ball.
Reference: The crystal ball illusion from our JCG partner Kristoffer Sjogren at the deephacks blog.
