Linus Arver <linusa@xxxxxxxxxx> writes: > Josh Steadmon <steadmon@xxxxxxxxxx> writes: > > Sorry, one more thing worth considering is the ability to add tests > inline with production code (where the test code can be removed in > production builds). There are a number of benefits to this and, I think > it is a useful feature to have. I saw this feature being advertised for > a C++ testing framework called doctest [1], but I assume it is also > possible in C. Could you include it as another (nice to have?) feature > under the "Developer experience" category? (Or, reject it if this > "inlined tests" style is not possible in C?) > > [1] https://github.com/doctest/doctest I suspect it's possible in C, but it's not that desirable for Git. - Inline tests are, by nature, non-production 'noise' in the source file, and can hamper readability of the file. This will probably be exaggerated in Git because our interfaces weren't designed with unit tests in mind, so tests may be extremley noisy to set up. - The described inline approach seems to be to build the same executable but with different flags. But for libification, we'd want to verify that we can build a separate executable with only a subset of files. A natural way to do that is to have unit tests in a separate file and for that to depend on only the subset we want.
