What is a good time to run slower tests? My full test suite takes around 4 minutes to run, and it’s trending upwards. I am a solo developer, so I run it pre-push.
And what about tests that only need to run intermittently, such as broken link checkers?
Is there a reason for that? I figure that catching bugs before pushing is faster than getting an email from GitHub, and my hardware already has all the containers running. Spinning up machines in the cloud for this feels wasteful.
if you want to reuse the local setup for ci or pushing broken code is somehow undesirable, then run all the tests pre-push
i tend to run only the fast set of tests, or a subset of the environments matrix, on pre-push — CI can take care of the rest while, i move onto do something else
when working with other the CI status is what matters
Comments
What is a good time to run slower tests? My full test suite takes around 4 minutes to run, and it’s trending upwards. I am a solo developer, so I run it pre-push.
And what about tests that only need to run intermittently, such as broken link checkers?
your ci setup should take care of the slow tests — for most folks this is github actions
pre-push can run the faster unittest set, ci will run the integration set
aim to keep pre-push duration under 10s
Is there a reason for that? I figure that catching bugs before pushing is faster than getting an email from GitHub, and my hardware already has all the containers running. Spinning up machines in the cloud for this feels wasteful.
if you want to reuse the local setup for ci or pushing broken code is somehow undesirable, then run all the tests pre-push
i tend to run only the fast set of tests, or a subset of the environments matrix, on pre-push — CI can take care of the rest while, i move onto do something else
when working with other the CI status is what matters