It is a truism: tight coupling is bad. Object-oriented blah blah… but that only applies to APPLICATION STACKS. Test is not app stack.
Tight coupling is DESIRABLE in test
If a test is tightly coupled to the unit under test (UAT) then the test will respond (pass or fail) depending tightly on the behavior (quality) of the UAT.
If a test isn’t brittle, fragile, tightly-coupled — all the things that are bad in object oriented production design. If a test isn’t designed for fragility, for sensitive response, what good is the test?
To be useful, a test must be tightly coupled to the unit under test
A common mistake made by teams experimenting with functional testing is to create “robust” Selenium tests that do not fail even if there are large variations in the UI. Such tests are not useful because they return no significant feedback.
If anything can change in the UI and the test will pass, then what is the point of the test? Instrumetnation should be sensitive, that is just inductive reasoning given the larger context of monitoring as testing, for which see below (hat tip: Matt Heusser)
Does this have some bearing on refactoring?
I don’t think so. By definition refactoring improves code without breaking tests. So the fact that the test are tightly coupled to behavior should not matter for refactoring purposes because refactoring does not change behavior only code.
Can you provide a counter example
Once I had to debug a test system that had sophisticated test helpers. The test helpers were a loosely coupled abstraction layer that among other things performed assertions. Because of the cleverly flexible abstractions of the helpers it was impossible to determine exactly where an assertion had been called. The system was replaced with a non-system of tightly coupled binary assertions and this was found to be more useful.