Split tests into public and internal ones #1037

1. 
   sipa commented at 8:36 pm on December 7, 2021: contributor

   The current unit tests are all built against the library’s internal source code directly. That means they have the advantage of being to test internal functions that aren’t exposed from the library, but it also means the tests cannot actually run against the normal release build of the library.

   To improve this:

   • Split the tests into separate public API tests, and internal tests.
   • A public test binary: public API tests, linked against the release build of the library (no -DVERIFY).
   • An internal test binary: #include’s the library code directly, plus public API tests, plus internal test (compiled with -DVERIFY).
2. sipa cross-referenced this on Dec 23, 2021 from issue Add _fe_half and use in _gej_add_ge and _gej_double by peterdettman
3. real-or-random cross-referenced this on Jan 5, 2023 from issue Native jacobi symbol algorithm by sipa
4. 
   real-or-random commented at 7:29 am on January 5, 2023: contributor

   I also see some value in running the internal tests without -DVERIFY. This would exercise a lot of functions with their production source.

   That doesn’t mean that we’ll get the same compiler output as in production (but probably the compiler will be closer to production at least). And it will catch cases in our source code, in which VERIFY code introduces real differences (which it should not).

   So it’s not perfect but tests are never perfect. I think this is a low hanging fruit, given that it should not be a lot of effort. It will just be a second internal test binary.

5. real-or-random cross-referenced this on Jan 5, 2023 from issue tests: Add noverify_tests which is like tests but without VERIFY by real-or-random
6. real-or-random added the label assurance on Jan 5, 2023
7. sipa referenced this in commit cbe41ac138 on Jan 9, 2023

Contributors
sipa real-or-random

Labels
assurance