Closed jayqi closed 7 months ago
Continuing discussion from here with @TylerGrantSmith:
I agree, and that is why I haven't worked on the test yet. It does raise a methodological question for me though. If you were to take the latter path and modify an existing test package, what checks are there to guarantee it doesn't "break" the tests it was originally designed for.
For example, with with the silverstein test package in #263, the structure of the classes is fairly specific and it would be easy to modify the package in a way that would not cause the associated test to fail, but the test would not be working as intended.
In general, I think the best way would be to add new classes that are independent and don't inherit from or depend on existing test classes in those packages. Then they would be edge-disjoint subgraphs, and for the most part shouldn't affect any tests about the original classes. (If there are normalized graph-level metrics being checked, we'd just need to regenerate those values.)
One possible thing that can happen is that class
A
in packageaaa
is a child class ofB
from packagebbb
.This is something that we don't currently test. It led to a bug addressed by #262. We should add a test for this. See here for some discussion.