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.

  • nous@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    5 hours ago

    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…