Are there any ramifications in using test_patterns?

Help Wanted
1

Team,

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 test_patterns knob.

1 Like
2

Currently, the issues that are not raised in test files are:

  1. Unused code is not detected currently in tests
  2. Error value returned from a function is unused

We are going to remove more issues, mostly performance and security, from test files.

The issues are ignored only because they do not make sense in tests, and ignoring them reduces the noise. If you would like to fix all code quality issues in tests too (including performance, security and a few antipatterns), you can leave the test_patterns part out.

1 Like
3

Thanks for the detailed response.