Absolutely. They were tests over a big ball of mud in a company I had joined recently.
This is, I think, the only good way to work with what is probably (unfortunately) the most common type of real world code architecture.
If your testing approach cant deal with big fragile balls of mud then it is bad. This is why I dont have a lot of respect for the crowd that thinks you must DI first "in order to be able to test". Such architectures are fragile and will break under attempts to introduce dependency inversion.
>Compared to testing APIs or Unit tests they are though.
In the above example there probably wasnt a single code interface or API under the hood that was any good. Coupling to any of those interfaces was fragile with a capital F if you actually expected to refactor any of them (which I did).
Even for decent quality code, the freedom to refactor interfaces is wildly underrated and it is curtailed by coupling a test to it.
Absolutely. They were tests over a big ball of mud in a company I had joined recently.
This is, I think, the only good way to work with what is probably (unfortunately) the most common type of real world code architecture.
If your testing approach cant deal with big fragile balls of mud then it is bad. This is why I dont have a lot of respect for the crowd that thinks you must DI first "in order to be able to test". Such architectures are fragile and will break under attempts to introduce dependency inversion.
>Compared to testing APIs or Unit tests they are though.
In the above example there probably wasnt a single code interface or API under the hood that was any good. Coupling to any of those interfaces was fragile with a capital F if you actually expected to refactor any of them (which I did).
Even for decent quality code, the freedom to refactor interfaces is wildly underrated and it is curtailed by coupling a test to it.