On Thu, Oct 24, 2019 at 10:15:29AM +0000, Luis Chamberlain wrote:
On Wed, Oct 23, 2019 at 05:42:18PM -0700, Brendan Higgins wrote:
With that, I think the best solution in this case will be the "__visible_for_testing" route. It has no overhead when testing is turned off (in fact it is no different in anyway when testing is turned off). The downsides I see are:
- You may not be able to test non-module code not compiled for
testing later with the test modules that Alan is working on (But the only way I think that will work is by preventing the symbol from being inlined, right?).
- I think "__visible_for_testing" will be prone to abuse. Here, I
think there are reasons why we might want to expose these symbols for testing, but not otherwise. Nevertheless, I think most symbols that should be tested should probably be made visible by default. Since you usually only want to test your public interfaces. I could very well see this getting used as a kludge that gets used far too frequently.
There are two parts to your statement on 2):
a) possible abuse of say __visible_for_testing
I really don't like the idea of littering the kernel with these. It'll also require chunks in header files wrapped in #ifdefs. This is really ugly.
b) you typically only want to test your public interfaces
True, but being able to test the little helper functions is a nice starting point and a good building block.
Why can't unit tests live with the code they're testing? They're already logically tied together; what's the harm there? This needn't be the case for ALL tests, etc. The test driver could still live externally. The test in the other .c would just have exported functions... ?