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
An initial simple unit test framework #344
Conversation
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## unstable #344 +/- ##
============================================
- Coverage 68.45% 68.42% -0.04%
============================================
Files 109 109
Lines 61671 61671
============================================
- Hits 42217 42198 -19
- Misses 19454 19473 +19
|
I think just the act of pulling this out into their own files will increase awareness of these tests (and hopefully encourage new additions). I personally didn't even know these existed until you pointed them out to me For mocking - just to zoom into this real quick - my understanding is the process would look something like:
Let me know if that is right. If it is, I guess a limitation of this approach is that we can't have one test mock something and another use the real implementation (without different build targets). But I don't think it will be an issue. I hope we can steer clear of mocks as much as possible anyways. Also - I kinda like that it will be "hard" (in comparison to other test frameworks) to mock something. I think a lot of overuse of mocks comes because it is the "easy" path. @PingXie, you were also tagged, any thoughts? Overall I think the minimal/lightweight test framework approach is a good direction for the project and I am aligned |
Yes, it would be something like this.
You can. You can have it point to an intermediary function which can dynamically determine which one to use. I know GMOCK supports some of that, so by default it will call the real function. You could build all functions to use the mocks, and then have GMOCK override it specifically for the test you are writing.
Yeah. I tried to limit the amount of time I spent on this incase nobody liked it. My vision is i'll cleanup these two tests, setup the daily and CI, and then commit it and ask someone from the community to help port the rest of the tests. |
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
I like this unit test framework. Ship it! |
Signed-off-by: Madelyn Olson <matolson@amazon.com>
Signed-off-by: Madelyn Olson <matolson@amazon.com>
Signed-off-by: Madelyn Olson <matolson@amazon.com>
Signed-off-by: Madelyn Olson <matolson@amazon.com>
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
@PingXie @murphyjacob4 Ok, this should be ready now. I'm a little uncertain about compatibility on all distributions though. I got some weird errors on the version of CentOS I run, but it seemed to be working on a fresh install. I've tested on centos, ubuntu, and macos. I also didn't enable it on the daily CI run, since I think that runs long enough as it is. |
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.
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.
It would be nice to capture the follow up(s) after this PR. Few things I observe are:
- Migrate the legacy unit tests to this framework.
- Get rid of
SERVER_TEST
macro. - Introduce mechanism to filter unit tests to run. Will allow flexibility during dev cycles.
The test framework also parses several flags passed in, and sets them based on the arguments to the tests. | ||
|
||
Tests flags: | ||
* UNIT_TEST_ACCURATE: Corresponds to the --accurate flag. This flag indicates the test should use extra computation to more accurately validate the tests. |
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.
Where do we use this test flag?
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.
It's used in the ziplist test, that is still on the older framework.
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.
Looks good to me!
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
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.
@madolson Great! Please merge this so we can avoid merge conflicts when it's hanging for too long. Or merge the CRC64 optimization PR first maybe?
I did CRC one first, then rebased ontop of this one. |
All the intset unit tests are migrated to new test framework as part of #344, but the old framework declaration is missed to remove from intset.h. So removed the code. Signed-off-by: Shivshankar-Reddy <shiva.sheri.github@gmail.com>
Here was my attempt at a unit test framework, partially ported over from redis/redis#12085, but it is slightly different.
The core idea was to take a lot of the stuff from the C unity framework and adapt it a bit here. Each file in the
unit
directory that starts withtest_
is automatically assumed to be a test suite. Within each file, all functions that start withtest_
are assumed to be a test.See unit/README.md for details about the implementation.
Instead of compiling basically a net new binary, the way the tests are compiled is that the main valkey server is compiled as a static archive, which we then compile the individual test files against to create a new test executable. This is not all that important now, other than it makes the compilation simpler, but what it will allow us to do is overwrite functions in the archive to enable mocking for cross compilation unit functions. There are also ways to enable mocking from within the same compilation unit, but I don't know how important this is.
Tests are also written in one of two styles:
@PingXie @murphyjacob4 We discussed this as the OSS summit, so trying to get this back up somewhere.