Post #1295641

2026-04-15 07:38 UTC

@thirstybear @tdpauw @samir @mrksdck I disagree that e2e tests have to be slow. In the days of Oracle / SQL Server, yes, but eg Mongo’s in-memory mode (added >10y ago) means API acceptance tests took ms to run, and under a minute for the entire suite. You could do outside-in and add unit tests for the gaps. The is exactly how the GOOS book talks about working.

Replies (3)

@samir@mastodon.functional.computer 2026-04-15 07:43

@chrisoldwood @thirstybear @tdpauw @mrksdck I’m hesitant to couple tests to the DB like this, even when it’s a really fast DB, but I can definitely agree that it’s not subject to the same failures as e.g. a bazillion WebDriver tests. I’ve done it myself with PostgreSQL in two previous jobs (though TBF, this was on integration layers; effectively very large “adapters” in ports+adapters parlance). There’s a flag to disable fsync which is really dangerous in production but great for testing.

Open ##1295642
@chrisoldwood@mastodon.social 2026-04-15 07:46

@thirstybear @tdpauw @samir @mrksdck I’ve just finished a gig where there are only unit and component tests, nothing automated involving the outer layers of the onion. All the non-automated testing involves shared infra because nobody took the time to get that going, so there are huge gaps and it takes time to regression test. They were web APIs and there are Azure local emulators for all the internal dependencies.

Open ##1295643
@thirstybear@agilodon.social 2026-04-15 08:07

@chrisoldwood @tdpauw @samir @mrksdck Agreed - acceptance tests need to be fast as well. And if you can be confident that your slow components can be in-memoried with an acceptable degree of risk, then do it. One thing that I'm flummoxed by is how to in-memory AWS cloud services like databases… 🙂 Usually had to shrug our shoulders, pull in H2 equivalents and hope it matches AWS’ idea of Postgres compatibility closely enough.

Open ##1295655