|
|
|
|
|
|
by creesch
514 days ago
|
|
|
> Some of the most useful tests Ive worked with HAVE had a large GUI tip. The GUI behavior was the most stable surface whose behavior was clearly defined which everybody agreed upon. This might be true, but that might also have said something about the layers below that and actually be a symptom for a larger issue within the development organisation. > GUI tests are not inherently fragile or inherently too slow either. Compared to testing APIs or Unit tests they are though. Not only do you need to navigate an interface with a machine that is actually intended for humans, you need to also deal with the additional overhead. |
|
|
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.