Back in the day when I used to make "webapps" - our integration tests were an epic faff.

Often times using things like cucumber to describe a set of interactions, in the days before headless chrome it'd drive selenium which would literally open Firefox on your desktop and start navigating the site.

It did it's job but the feedback loop was slow.

Today I mainly write libraries, cli tools and the occasional small HTTP API. I still have unit and integration tests but they are all just standard pytest functions. I can run each type individually, my definition of an "integration" test is either something that talks to the outside world in some capacity, or something that is really slow (mostly running an ml model these days).

I much prefer today's approach, but admittedly I work on things with far fewer points of interaction which I think greatly simplifies the work.

I am so mad that the mockists stole the word "unit test" for their thing. The original definition of a unit test was writing "integration" tests for each of the sub-components of a system.

(Mockist tests are fine for people who really want them, as long as you delete them before checking in the code.)