Why is there such little emphasis on “traditional” testing, that is, regular unit tests? At least some portion of the code base is surely suitable for normal unit tests. For example data structures, scheduling algorithms, file systems, ...
I am well aware that it's also possible to have dependency injection in C by using structs with function pointers, but I think we can all agree that it's a lot less pleasant to use than C++ abstract base classes, Go interfaces or Rust traits. This is why the Linux kernel only tends to use this sparingly (e.g., inode operations).
Unless I've missed something? I've only ever worked in Java so maybe things are different in C-world,
Well, for one thing, there are no classes in C. :) It is possible but unfun to emulate them with function pointers. Iiuc, little of the Linux kernel is written in that style.
Also, FYI, for many years we did DI without frameworks, using the factory pattern and other techniques. It wasn't always fun but it can certainly be done without Spring or whatever the new thing on the block is.
object-structs with function-pointers-for-methods are super-common in the Linux kernel and basically used everywhere for everything where modules can plug something into the kernel (e.g. virtually all drivers have at least one of these).
Abstract base classes, interfaces and traits allow you to add dependency injection with relatively little code. In C it is simply more of a hassle, which is why folks don’t tend to do it.
> it takes a crazy amount of effort
> it's also possible to have dependency injection in C by using structs with function
> pointers, but I think we can all agree that it's a lot less pleasant to use than C++
> abstract base classes
If you want to sort an array:
int arr[] = {5, 10, 15, 17, 20};
size_t size = sizeof(arr) / sizeof(*arr);
QSORT(arr, size, arr[a] < arr[b]);
ssize_t index;
BSEARCH_INDEX(index, size, arr[index] - 5);
// Now 'index' has the result.The fact that you hate function pointers and void* context pointers is an exact confirmation of my premise: people think it’s too much of a hassle.
> With regards that anything can be streamlined: sure, but it’s also about the amount of investment
> that would take.
> The fact that you hate function pointers and void* context pointers is an
> exact confirmation of my premise: people think it’s too much of a hassle.
As for mocks, the fact that they're hard to do in C may be a feature in disguise...
I agree: UT is a pain to write precisely because you need to spend quite a bit of effort to stub out your dependencies. And when you do stub things out, they usually end up being “dumb” stubs where the function just returns EOK. Thankfully, there has been a recent effort in XR to leverage the Cmocka test framework to make stub functions a bit smarter.
Even if you have great UT, there is a bigger issue: the UT only tests and validates your code, but does not validate interactions with other components. With a system as complex as IOS-XR, there are non-trivial situations that you simply cannot trigger with UT.
This is where IT shines, imo: you can bring up a full router and test all known interactions at the system level. The test runtime is much longer, of course, but in my experience, it’s worth the wait to avoid hitting the issue down the line.
† Regression testing was certainly known then, but it was not a dogmatic movement yet.
To solve this, you would need to either use a hierarchical decomposition of subsystems or do some crazy mocking to run subsystems outside of the full kernel.
There is a recent project (KUnit) to add a unit testing framework to the Linux kernel, but it remains to be seen how much adoption it will get.
This is basic design for unit testing but it's impossible in Linux because Linux lacks a zero-cost abstraction that would let you mock out a device. C only has costly abstractions such as tables of function pointers.
FWIW, I agree 100% with you. It's just simply not the way the world works.