A more natural metric for “Isolation”: expression, method, class, file, package, library, application, container (or machine/OS/box), cluster (or intranet), internet. A sort of generalization of lexical scope, or global variables. You might also split it up by mutability; testing your application’s installer might need ‘read’ access all the way up to the internet for downloading dependencies, but require write access only up to the container.
I wonder how does the categorisation help thinking in the TDD process. It seems to me that such tags, although very precise when looking back at the tests that are already written, would be too much for me to remember and to think about upfront.
There are manu possible classes but each axis is simple enough to remember. A team may need some time to get used to the idea but once it happens - it helps. So, technically when you write a test you always know that you shouldn’t break encapsulation, should try to concentrate on contracts and should avoid any integrations. When you need something apart of that - you may think a bit how to choose the class with minimal weight which would work for you. The same applies for refactorings - you always have some basic guidelines on how to make a test “better”.
It’s very hard to explain people thinking in traditional terms why their whitebox-evil tests don’t return invested efforts.
Not a day goes by where a blog post doesn’t tell me I’m doing it wrong.
This is a good place to start thinking about the classification and construction of tests differently.
A more natural metric for “Isolation”: expression, method, class, file, package, library, application, container (or machine/OS/box), cluster (or intranet), internet. A sort of generalization of lexical scope, or global variables. You might also split it up by mutability; testing your application’s installer might need ‘read’ access all the way up to the internet for downloading dependencies, but require write access only up to the container.
Thanks for the ideas, I’ve added them to the post.
I wonder how does the categorisation help thinking in the TDD process. It seems to me that such tags, although very precise when looking back at the tests that are already written, would be too much for me to remember and to think about upfront.
There are manu possible classes but each axis is simple enough to remember. A team may need some time to get used to the idea but once it happens - it helps. So, technically when you write a test you always know that you shouldn’t break encapsulation, should try to concentrate on contracts and should avoid any integrations. When you need something apart of that - you may think a bit how to choose the class with minimal weight which would work for you. The same applies for refactorings - you always have some basic guidelines on how to make a test “better”.
It’s very hard to explain people thinking in traditional terms why their whitebox-evil tests don’t return invested efforts.