Spent the week babysitting a CI pipeline that happily fails e2e tests at 03:17 AM and never on my laptop. After three rollbacks and one sacrificial Selenium script I have a new worldview: unit tests are polite love letters to future you, integration tests are noisy group therapy sessions where everyone admits their dependencies, and end-to-end tests are full-on necromancy that only work if you chant the exact right incantation and feed the CI a donut.
Team policy proposal: write unit tests to document intent, use integration tests to catch honest misunderstandings, and only run e2e in pairs with snacks and a printed backup plan. If your e2e passes on the first try, you are either a wizard or lying.
I find most people don’t create good unit tests. They create them too small which results in them being fragile to change or near useless. They end up being a tray for future you not a love letter.
The number of times I have refactored some code and broken a whole bunch of unit tests is unreal. These types of tests are less then useless. If you cannot refactor code then what is the point in a unit test? I don’t need to know that if I don’t change the code under test it doesn’t break… I need to know that when I change code my assumptions still hold true.
We should be testing modules as a whole using their external API (that is external to the module, not necessarily the project as a whole), not individual functions. Most people seem to call these integration tests though…
Eh if the behaviour is changing then I think it’s normal and good that the associated unit tests should also change.
Obviously you can get annoying with unit tests, but if they’re tiny and fast, and trivial to update then I like them as a truth check that the behaviour is changing as I expect.