Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.65%. Comparing base (1af8368) to head (8220172).
Report is 3 commits behind head on main.

@@            Coverage Diff             @@
##             main     #214      +/-   ##
==========================================
- Coverage   97.66%   97.65%   -0.02%     
==========================================
  Files          32       32              
  Lines        1587     1618      +31     
==========================================
+ Hits         1550     1580      +30     
- Misses         37       38       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I believe we'll also need to make some changes to the tests/algorithm/configurations/algorithm_configuration.json sample file as some of the functions it references are no longer available. (Really that file should have been updated when we did the function rename, but it looks like we missed it)

@ericbuckley What actually is the purpose of tests/algorithm/configurations/algorithm_configuration.json? I definitely missed it making my pass, but since the tests all passed without updating it, is it actually being invoked anywhere? It seems to me like we can just delete it but want to make sure I'm not missing something.

@ericbuckley What actually is the purpose of tests/algorithm/configurations/algorithm_configuration.json? I definitely missed it making my pass, but since the tests all passed without updating it, is it actually being invoked anywhere? It seems to me like we can just delete it but want to make sure I'm not missing something.

• tests/unit: these are unit tests (some might technically be integration, but its nuanced), we have a GH action workflow to run these in PRs
• tests/algorithm: this is a set of scripts we developed to test an algorithm configuration with a known set of test cases. Over the fall, NBS asked us many times how does the code handle edge case X. Our answer was always, it depends on how you have it configured. This project was our way to respond to that question and create developer tooling that allows those types of questions to be answered. These are not automated, developers need to go through the steps in the README to run them.
• tests/performance: another set of scripts developed to see how fast the API can process linkage requests using synthetic data. This is useful for verifying refactors are still performant and helping developers identify bottlenecks along the way. These are not automated, developers need to go through the steps in the README to run them.

I'm guessing some documentation like the above would be helpful in the top level README 😁

Algo config tests have been updated and some new details added to the README to cover this explanation!

For sure. Would you actually rather we delayed merging this until after the release?

For sure. Would you actually rather we delayed merging this until after the release?

If we're going to do it, I'd rather do it sooner than later. I'd only vote for holding off, if you're not 100% sure this is the right direction to go in.

No hesitation on my end. I very strongly believe that pushing just THE DIBBs Algorithm will exponentially reduce confusion and will put our most significant contributions front and center.