Recently, I struggled for a couple of hours to understand why the API tests of one project were slow. In theory, we designed tests to run in a fully parallel way – the duration of tests should be close to the longest-running test. Unfortunately, the reality was different. Tests took 7x longer than the slowest test without using 100% available resources.

ThreeDotsLabs' platform is  dedicated to providing insights and resources for software engineers and technology enthusiasts. Through articles, tutorials, and open-source projects, ThreeDotsLabs offers insights into software development best practices, design patterns, and emerging technologies. Developers can learn about building scalable architectures, microservices, and cloud-native applications to solve real-world problems effectively.

Three Dots Labs

Optimizing Go tests can significantly speed up their execution. Visualizing test output is crucial for understanding inefficiencies, which can be addressed by using tools like 'vgt'. The post highlights the nuances of utilizing parallelism in Go tests using `t.Parallel()` and the `-parallel` flag, showcasing how default settings often don't maximize test speed due to CPU-bound limitations. It also explains best practices for configuring and linting tests to run efficiently in CI environments.

Optimising and Visualising Go Tests Parallelism: Why more cores don't speed up your Go tests

It’s hard to fix a problem that you can’t see

Parallelism quirks: does grouping tests with t.Run() affect performance?