My codebase looks something like this where some folder contains only test files that contains the actual implementation and its respective tests and some folders contains standalone go packages.
. |-- README.md |-- ast // standalone go package | |-- astcomments.go. | `-- compiler |-- bits // standalone go package | `-- bitcount.go |-- go.mod `-- practise |-- common | `-- utils.go |-- interview // package with tests that contain actual implementation | |-- 2nd_largest_item_bst_test.go | |-- apple_stocks_test.go | |-- balanced_binary_tree_test.go | |-- binary_search_tree_test.go | |-- fibonacci_number_test.go
Currently, I am not using the
test_patterns knob in
deepsource.toml as this article suggests that it will ignore few issues not relevant to tests. However, I want to understand what kind of issues are ignored.
As running deepsource on my repo helped me in refactoring the code with fewer lines and improved readability, wouldn’t want to miss out on such refactoring feedback by adding