Hacker News new | past | comments | ask | show | jobs | submit
mananaysiempre | on: The 49MB web page
“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 | 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 | root | 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 | root | 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 | root | parent
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 | parent
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.