-
Notifications
You must be signed in to change notification settings - Fork 957
Description
The problem/use-case that the feature addresses
See also conversation in: #94 (comment)
Integration Testing is the (usually black-box) testing of the application as a whole. We do a pretty good job for integration testing, using a TCL framework. Though there are other options for integration testing frameworks, there's no immediate driver to change this.
Unit Testing is detailed (often white-box) testing of specific, well-defined, code units - independent from the fully integrated application. The original Redis code did a poor job in defining "units". Lots of global variables, poorly defined interfaces, ambiguous scope. Consistent with this lack of focus on units was/is the lack of focus on unit testing. Instead, relying on integration testing.
@daniel-house says "the code is so highly optimized that it is difficult to write isolated tests for many of the functions". While I wouldn't use the word "optimized" to describe the structure, I concur that many areas are not currently well suited to unit testing. But as we move the yardstick further, we're seeing that many areas ARE (or are becoming) well suited to unit testing.
Today, we have a small collection of unit tests using an ad-hoc mechanism in src/unit. However we have no mechanism to mock functions between units, and no general support from an advanced unit testing framework. This continues to prohibit or discourage the development of unit tests, deepening our tech-debt in this area.
Description of the feature
@PingXie says:
Btw, I think we actually need a true unit test framework soon, something like https://github.com/google/googletest, which complements the integration test framework, as opposed to replacing it.
Google's gtest/gmock provides a fairly comprehensive framework for developing unit tests for C/C++. While other options exist, this is a good option. @madolson says "I just don't want to also add C++ to the language folks need to understand". I agree with this sentiment, and though gtest/gmock are technically C++, in practical testcase development, it's mostly straight C development with some C++ boilerplate. With a short example, this won't create a significant barrier for C-only developers.
I recommend that gtest/gmock support (or equivalent) is added to the build, with a new folder for gtest unit tests. A few example tests should be provided, including a test which performs mocking. I do not recommend conversion of existing tests in src/unit. These can remain, using the existing ad-hoc tools. This provides a path forward without impacting the current ecosystem.
Alternatives you've considered
Any framework that supports C unit testing, with function mocking, would be an option.