Nearly a decade back I wrote a lot of browser CI tests with headless chrome as well as browser stack. I loved the idea, but they just didn’t handle things being a bit outside of perfect IRL, like taking a moment longer to load etc. They ended up having a lot of waits in them, taking a long time to write and were prone to being flakey. The tests basically lacked “common sense” and it made me think that one day someone would figure out how to make them work better.

I’m wondering if there are new frameworks, workflows, startups that have made this stuff easier and better. I’m not really in tech anymore but I wouldn’t mind writing some tests if the experience was better.

  • abhibeckert@lemmy.world
    3·
    7 months ago

    Yeah I’ve given up on integration tests.

    We have a just do “smoke testing” — essentially a documented list of steps that a human follows after every major deployment. And we have various monitoring tools that do a reasonably good job detecting and reporting problems (for example, calculating how much money to charge a customer is calculated twice by separate systems, and if they disagree… an alert is triggered and a human will investigate. And if sales are lower than expected, that will be investigated too).

    Having said that, you can drastically reduce the bug surface area and reduce how often you need to do smoke tests by moving as much as possible out of the user interface layer into a functional layer that closely matches the user interface. For example if a credit card is going to be charged, the user interface is just “invoice number, amount, card detail fields, submit, cancel”. And all the submit button does is read every field (including invoice number/amount) and send it to an API endpoint.

    From there all of the possible code paths are covered by unit tests. And unit tests work really well if your code follows industry best practices (avoid side effects, have a good dependency injection system, etc).

    I generally don’t bother with smoke testing if nothing that remotely affects the UX has changed… and I keep the UX as a separate project so I can be confident the UX hasn’t changed. That code might go a year without a single code commit even on a project with a full time team of developers. Users also appreciate it when you don’t force them to learn how their app works every few months.