-
Notifications
You must be signed in to change notification settings - Fork 40
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
test: Add test datastore selection support #88
test: Add test datastore selection support #88
Conversation
Added my review. But at the same time I wanted to ask a bigger question, that we touched on during our last eng call. Do we want this multi datastore backend test method implemented programmatically, as its done here, or via tooling with a simpler implementation, that then uses |
Cheers John - will go through the line-specific items when I can. RE: loop vs make/aliases - I'm not keen on putting much in make-type files if we can avoid it, and I do like that it runs both by default when running go test ./... (even if we could move that to make/alias files) - a solid default will help stop devs from leaking bugs. |
77d80c2
to
8d68075
Compare
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.
Lets just quickly add Badger file store, incase theres some weird edge cases there.
}, nil | ||
} | ||
|
||
func getDatabases() ([]databaseInfo, error) { |
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.
Do we want to include Badger disk based DB as well as the in-memory version. Certainly some code paths internal to badger we won't hit if we only work with the Memory version.
I can't see how those extra codepaths would have any effects on the Defra codebase and tests, but if its easy to add to give some piece of mind, why not.
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.
Can do, but it would make the tests dependent on the file system (which maybe is a good thing for a Db project lol...), might have implications for the CI system?
59f7400
to
d145736
Compare
ok is always false here
d145736
to
716102a
Compare
Codecov Report
@@ Coverage Diff @@
## develop #88 +/- ##
===========================================
+ Coverage 54.03% 54.17% +0.14%
===========================================
Files 35 35
Lines 3633 3629 -4
===========================================
+ Hits 1963 1966 +3
+ Misses 1441 1435 -6
+ Partials 229 228 -1
|
Removed badger file-system from this branch, opening new issue #127 and new branch/review sisley/test/I127-test-against-file-system |
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.
LGTM
716102a
to
dc5037f
Compare
dc5037f
to
3609b6f
Compare
* Move discard to after error check * Fix if-else ok is always false here * Add support for running tests against multiple ds types
Closes #87
Change driven by recent bugs in development/production (fixes for those still outstanding cherry-picked in).
Hopefully we can add more stores to this, including file-based badger. Still seems quick to run go test ./... on my machine but we can change the defaults if/when it becomes an issue.