-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decompose and organize import-tests
script
#1165
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stalgiag this is such a good separation of concerns! Thanks much! I've left a few inline comments and suggestions but nothing blocking
/** | ||
* Strategies for different test format versions. | ||
*/ | ||
const testFormatStrategies = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neat!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stalgiag this looks good to me!
DB construction that at least one of the tests would surface an errant change in functionality. If this is not the case, and there is room for this to introduce breaking changes
Yep a test should exist to confirm the state of the TestPlanVersion rows is the same before and after an import.
The other tests not breaking still serve as an indicator that all should be well given they're built around the import script but an explicit test like above should be done. It can be done in this PR or in another, I don't think this has to be blocked on that.
This pull request reorganizes and documents the code in the import-tests script. I tried to avoid changing functionality and only made minor code changes beyond breaking big functions up, grouping related functions into specific modules, and add JSDoc comments.
The database builds and the tests pass. I assume that this script is so foundational to DB construction that at least one of the tests would surface an errant change in functionality. If this is not the case, and there is room for this to introduce breaking changes, then I am okay with not merging out of an abundance of caution.
I also recognize that this reorganization is highly damaging to the git history. If we don't feel that the tradeoff in readability/maintainability is worth it then I would be happy to discard this PR.