|
|
|
|
|
|
by gehen88
896 days ago
|
|
|
I was hoping for some interesting insight to be shared, but no it’s just a shallow opinion piece on why E2E is better than unit tests for web interfaces, without really explaining why. The author misses that component tests don’t have to be like unit tests at all, they are more like integration tests if you test entire pages (which are components too), use actual user interactions and mock only the I/O (mostly network) layer. It’s like E2E without spinning up a backend. |
|
|
The main objection heard will be: "It takes x hours and n servers to set up an E2E environment."
Infrastructure is hard, and with cloud functionally unlimited, so people write a mock and move on with their life.
To do E2E well your culture needs to support it. You need to be able to spin up, run and summarize an E2E test in less than 20 minutes. Set your test up to END on the hour (not start, end) SO that if there is an outage no one can make the excuse that the "meeting already started". If the test fails every one who has changes in that build drops what they are doing and treats it like a production outage. The technological magpies, collecting shiny things and adding them to the stack has to stop, because you dont want to add "new tech" to build time. You may need to run some of your own infra to get this done. Some servers in a closet some where will do wonders for your bills.
Because you're always building your environment from scratch, in the event of a real disaster you know what it takes to put a large chunk of your environment back together. Your like going to have a pretty lean stack, one that scales diagonally (at this point go look at AWS spot pricing and how much you can save if you can scale that way).
That isn't to say you should not unit test. Things that are clearly stand alone, like well defined validation, things that are ugly (that 20 condition switch statement that powers some esoteric edge case of business "logic") should get unit tests. Places where you can leverage fuzzing easily should have unit tests! Anything that has a dependency tree or needs a mock, should be skipped and addressed with an end to end test.
What will you get in the end? A production environment with every bit of unneeded complexity stripped from it (and probably a lower cloud bill). An aversion to adding anything that doesn't have VALUE to your stack. A ruthless eye for what qualifies as "bloat" (hint, a LOT of it is bloat). The removal of code for codes sake (mocks) and layers of duplication (an E2E create user test can exercise a lot of code, and replace a lot of unit tests at various levels). The whole team having a much better understanding of how your infrastructure is built and deployed.