“Craptop duty”[1]. (Third time in three years I’m posting an essentially identical comment, hah.)

[1] https://css-tricks.com/test-your-product-on-a-crappy-laptop/

tom1337 11 hours ago | parent | next [-]

I now wonder if it'd be a good idea to move our end to end tests to a pretty slow vm instead of beefy 8 core 32gb ram machine and check which timeouts will be triggered because our app may have been unoptimized for slower environments...

▲

mananaysiempre 10 hours ago | parent | next [-]

For blocking presubmit checks, getting the fastest machine you can is probably reasonable. Otherwise, the advantage of the craptop approach is that it needs basically no infra work and gives an immediate impression of the site, and not CI, being slow.

If you’re willing to build some infra, there’s probably a lot more you can do—nightly slow-hardware runs come to mind immediately, browser devtools have a convincing builtin emulation of slow connections, a page displaying a graph of test runtime over time[1] isn’t hard to set up, etc.—but I don’t really have experience with that.

[1] See e.g. https://arewefastyet.com/win11/benchmarks/overview?numDays=3....

	▲	gbuk2013 9 hours ago \| parent [-]
		I kid you not a few jobs ago I found several race conditions in my code and tests by running them at the same time as a multi threaded openssl burn test. :)

▲

bombcar 10 hours ago | parent | prev [-]

It’s worth doing at least sometimes; schedule an over The Weekend-to-Weekend test on slow hardware and log the issues.

Even if you don’t fix them, knowing where the weak points are is valuable for when they do snap in production.

▲

KaiMagnus 10 hours ago | parent | prev [-]

Gonna bookmark that article for tomorrow, craptop duty is such a funny way to put it.

Similarly, a colleague I had before insisted on using a crappy screen. Helped a lot to make sure things stay visible on customers’ low contrast screens with horrible viewing angles, which are still surprisingly common.