You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix unit tests to avoid data race in pipelines (#2602)
Fix unit tests to avoid data race in pipelines
Problem: Users want to parallelize unit tests without having data race issues
Solution: Modify unit tests to be independent of variables, maps/structs to avoid data race when tests run in parallel.
Copy file name to clipboardExpand all lines: docs/developer/testing.md
+2
Original file line number
Diff line number
Diff line change
@@ -36,6 +36,8 @@ the [Counterfeiter](https://github.com/maxbrunsfeld/counterfeiter) tool. Counter
36
36
implementations of internal and public interfaces, allowing us to isolate and control dependencies during testing. It
37
37
simplifies the process of mocking and stubbing, making our tests more robust and flexible.
38
38
39
+
**Parallelize unit tests**: In general, all tests should be designed to run in parallel for faster execution and help uncover bugs. For standard Go tests, this requires adding `t.Parallel()` to every test and subtest. Ginkgo tests, on the other hand, automatically run in parallel without the need for additional configuration. If a component under test requires sequential execution, you can run tests sequentially by using an [ordered container](https://onsi.github.io/ginkgo/#ordered-containers) for Ginkgo tests or by omitting `t.Parallel()` from the go test or subtest. In such cases, it’s essential to include a comment explaining why parallel execution is not possible.
40
+
39
41
By combining BDD style tests, unit tests, and mock generation, we aim to achieve a comprehensive and maintainable
40
42
testing strategy. This approach enables us to ensure the correctness, reliability, and flexibility of our codebase while
41
43
promoting efficient refactoring and continuous development.
0 commit comments