-
Notifications
You must be signed in to change notification settings - Fork 310
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
Add unit tests to query generation functions for various databases #76
Add unit tests to query generation functions for various databases #76
Conversation
Codecov Report
@@ Coverage Diff @@
## master #76 +/- ##
=========================================
+ Coverage 57.32% 64.9% +7.58%
=========================================
Files 77 77
Lines 3810 3810
=========================================
+ Hits 2184 2473 +289
+ Misses 1595 1309 -286
+ Partials 31 28 -3
Continue to review full report at Codecov.
|
rand.Seed(123) // Setting seed for testing purposes. | ||
|
||
for _, c := range cases { | ||
t.Run(c.desc, func(t *testing.T) { |
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.
wow, i never knew about this but it's exactly what i've wanted and (poorly) re-implemented all over the place.
if s != c.failMsg { | ||
t.Fatalf("incorrect fail message: got %s, want %s", s, c.failMsg) | ||
} | ||
runtime.Goexit() |
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.
moot point if we go with my other pr (#77), but is this necessary? we don't have to have the same semantics of log.Fatalf (i.e. killing the process). If we take this out, we can reduce the amount of defer/waitgroup also, making this an easier func to understand
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.
I agree but if we don't kill the process, fatal will be called multiple times in a test case and thats something that the existing function stops from happening. That means tests would fail and I would have to have multiple fatalMsg
s to check each one.
I know it looks over-engineered but I didn't find a better way of replicating the current behavior in order that the tests reflect real-world usage.
@RobAtticus updated the tests based on your feedback. Waiting with further changes until PR #77 is merged to master. |
ef57f51
to
00454c0
Compare
@RobAtticus I rebased the PR with your latest changes and fixed them up to reflect them. Could you take another look at it? Thanks. |
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.
Couple of small things, but then you can merge
Covering query generation functions for Influx, ClickHouse and SiriDB databases. Tests are covering basic pre-generated outputs and provide visual sanity checks. More robust tests are left as a future task.
00454c0
to
c1bc78a
Compare
Covering query generation functions for Influx, ClickHouse and SiriDB
databases. Tests are covering basic pre-generated outputs and provide
visual sanity checks. More robust tests are left as a future task.