feat(treemap): allow configurable test dir#2805
Conversation
The new optional configuration option `tree_map_test_path_pattern` allows for choosing which e.g. `@relation()` findings that should be classified as test or source, when rendered in the tree map view. When omitted, the previous behavior of "anything within `tests/`" gets marked as a test. For example, `tree_map_test_path_pattern = "_test\.go$"` could be helpful for go projects. This implements strictdoc-project#2782
|
Hi @stanislaw, sorry that I took my time to implement this 😊 When implementing the suggested & agreed upon "list of globs" from #2782 I got a little discouraged by all nested loops/recursion, so I went for an old and trusted regexp-approach instead (without measuring performance, so I have nothing to stand on). I looked for usage of Please let me know if the implementation/tests aren't good enough, or any other pointers you'd like me to address. Best regards, |
| @@ -0,0 +1,91 @@ | |||
| <?xml version="1.0" encoding="UTF-8"?> | |||
There was a problem hiding this comment.
I just copied a nearby test, which is not super slim & focused at the new change..
There was a problem hiding this comment.
Yes, copying is of course fine but let's reduce it to the bare minimum we need to exercise this new feature.
In particular, let's remove this XML file. And also I think it should be enough to only leave this test function in the test file as it is the only one you are actually testing against:
TEST(MyTestSuiteName, TestName)
(the background for this is that StrictDoc has lots of test boilerplate and I try to reduce how much boilerplate is needed and used by each test)
| include_source_paths: List[str] = [] | ||
| exclude_source_paths: List[str] = [] | ||
| test_report_root_dict: Dict[str, str] = {} | ||
| tree_map_test_path_pattern: Optional[str] = None |
There was a problem hiding this comment.
I am curious if there is an opportunity for reusing the already implemented filtering mechanism. Could we use the same approach that is used for include_doc_paths and include_source_paths? These filters are based on PathFilter.
See around these lines:
path_filter_includes = PathFilter(
include_paths, positive_or_negative=True
)
This way the new tree_map_test_path_pattern will simply follow the same configuration interface (an array of lines to whitelist) and use the same filtering mechanism.
There was a problem hiding this comment.
Will look into this!
I would like the properties of "tests are within a certain path" but also allow "this path contains both tests & implementation" to coexist (for example to cover the go convention). I wonder what inline test definitions next to implementation (rust example) would look like, too 🤔
stanislaw
left a comment
stanislaw
left a comment
There was a problem hiding this comment.
The change looks very good overall, but I left a few comments.
2 participants
The new optional configuration option
tree_map_test_path_patternallows for choosing which e.g.@relation()findings that should be classified as test or source, when rendered in the tree map view.When omitted, the previous behavior of "anything within
tests/" gets marked as a test.For example,
tree_map_test_path_pattern = "_test\.go$"could be helpful for go projects.This implements #2782