git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v4 3/6] unit-tests: add if_test

From
Kyle Lippincott <spectral@google.com>
Date
Aug 2, 2024, 00:48 UTC
Message-ID
<CAO_smVi6hxYLYWPXautyHyYKV2eZitm3j0EFuSo7qbBAoGZvAw@mail.gmail.com>
In-Reply-To
<51ec32ed-f2f1-4993-92e5-1acfcdbb7c79@web.de>
On Thu, Aug 1, 2024 at 12:32 AM René Scharfe <l.s.r@web.de> wrote:
Show 15 quoted lines
>
> Am 01.08.24 um 00:04 schrieb Kyle Lippincott:
> >
> > I'm still not wild about the name, and I'm still not convinced of the
> > readability improvements. I still want to read `if_test(...)` as
> > having a condition in the parenthesis. Tests "skipping everything"
> > seems like an internal implementation detail that there's disagreement
> > on whether to expose to the test author/reader or not; maybe we should
> > redesign if we don't migrate to clar or some other test framework. Do
> > we get significant benefits from a test function continuing to execute
> > after the "skip everything" flag has been set?
>
> The idea is that the unit test framework may allow to skip individual
> tests in the future; see
> https://lore.kernel.org/git/c2de7f4e-e5dc-4324-8238-1d06795a2107@gmail.com/

I see. This functionality isn't currently available, but we may want it in the future. If that future ever happens, then we may be able to avoid some cleanup if we keep the setup the way it is, where `test__run_start` returns whether or not the test actually started. This future `--run` flag for the unit tests would be based on either (a) position in the file, like the integration tests, or (b) some substring of the description. Since the tests don't have a name, there's no ability for `--run` to operate based on that. Ok.

I still don't like the name, but I might be in the minority on this. Yes, there's a control structure in use to make this work with the syntax you desire, but unlike with `for_test`, there's many fewer edge cases added because of it: `break` and `continue` won't do anything with `if_test`. I suppose that we would still need to be concerned about the possibility of someone writing this:

if (condition)
    if_test("...")
        check_int(1, ==, 1);
else
    ...

I'm also still not personally sold on the value here. Single-expression tests can be written with `TEST(check_int(1, ==, 1), "equality")`, and having a single large function with all multi-statement tests in it is harder to follow, in my opinion, than the alternative where the tests are in a separate function. I can only really think of the case where the tests have inter-dependencies (ex: test 2 sets some state that test 5 relies on) for wanting them all in the same function, because then that dependency becomes a bit more obvious. However, getting that inter-test dependency to _not_ happen actually seems like a worthwhile goal (except for cases like strbuf, where if strbuf is inherently broken, we need to check that first and bail out). There's increased risk that someone will write a test like this (purely hypothetical example of some state being carried from one test to another; yes, you can accomplish the same terribleness with global variables, but more people have immediate negative reactions about globals):

int cmd_main(int argc UNUSED, const char **argv UNUSED)
{
    char tmp_path[PATH_MAX];
    if_test("alpha") {
        /* perform basic functionality checks, like strbuf does */
    }
    if_test("beta") {
        /* or some other "expensive" initialization we don't want to
do if everything is broken */
        sprintf("/tmp/tmp.%d", rand());
        do_something(tmp_path, ...);
    }
    if_test("gamma") {
        /*
         * if beta didn't run, or if tests get reordered such that
gamma executes before beta,
         * things are going to go very poorly here
        */
        do_something_else(tmp_path, ...);
    }
    return tests_done();
}

That said, I'm still not opposed enough to the idea to veto (plus I don't have anywhere near that kind of power, and shouldn't :)). I just don't think I'd ever use it.

Previous: René ScharfeNext: René Scharfe
Message 112 of 115 in “unit-tests: add and use TEST_RUN to simplify tests”
  1. 0/6 unit-tests: add and use TEST_RUN to simplify testsRené Scharfe, Jun 29, 2024
  2. 1/6 t0080: move expected output to a fileRené Scharfe, Jun 29, 2024
  3. Jeff KingJul 1, 2024
  4. Junio C HamanoJul 1, 2024
  5. Jeff KingJul 1, 2024
  6. Junio C HamanoJul 1, 2024
  7. Jeff KingJul 2, 2024
  8. René ScharfeJul 1, 2024
  9. Jeff KingJul 1, 2024
  10. 2/6 unit-tests: add TEST_RUNRené Scharfe, Jun 29, 2024
  11. phillip.wood123@gmail.comJul 2, 2024
  12. Junio C HamanoJul 2, 2024
  13. René ScharfeJul 2, 2024
  14. René ScharfeJul 2, 2024
  15. phillip.wood123@gmail.comJul 5, 2024
  16. René ScharfeJul 5, 2024
  17. René ScharfeJul 7, 2024
  18. phillip.wood123@gmail.comJul 8, 2024
  19. Junio C HamanoJul 8, 2024
  20. Junio C HamanoJul 11, 2024
  21. Phillip WoodJul 13, 2024
  22. Junio C HamanoJul 13, 2024
  23. phillip.wood123@gmail.comJul 8, 2024
  24. 3/6 t-ctype: use TEST_RUNRené Scharfe, Jun 29, 2024
  25. Josh SteadmonJul 1, 2024
  26. René ScharfeJul 1, 2024
  27. phillip.wood123@gmail.comJul 2, 2024
  28. René ScharfeJul 2, 2024
  29. 4/6 t-reftable-basics: use TEST_RUNRené Scharfe, Jun 29, 2024
  30. 5/6 t-strvec: use TEST_RUNRené Scharfe, Jun 29, 2024
  31. phillip.wood123@gmail.comJul 2, 2024
  32. René ScharfeJul 2, 2024
  33. 6/6 t-strbuf: use TEST_RUNRené Scharfe, Jun 29, 2024
  34. Josh SteadmonJul 1, 2024
  35. René ScharfeJul 1, 2024
  36. phillip.wood123@gmail.comJul 2, 2024
  37. René ScharfeJul 2, 2024
  38. phillip.wood123@gmail.comJul 4, 2024
  39. Phillip WoodJul 10, 2024
  40. René ScharfeJul 14, 2024
  41. Ghanshyam ThakkarJul 15, 2024
  42. Ghanshyam ThakkarJul 2, 2024
  43. René ScharfeJul 2, 2024
  44. Ghanshyam ThakkarJul 3, 2024
  45. Josh SteadmonJul 8, 2024
  46. Ghanshyam ThakkarJul 8, 2024
  47. Josh SteadmonJul 1, 2024
  48. Junio C HamanoJul 10, 2024
  49. Phillip WoodJul 11, 2024
  50. Junio C HamanoJul 11, 2024
  51. René ScharfeJul 14, 2024
  52. 0/6 unit-tests: add and use for_test to simplify testsRené Scharfe, Jul 21, 2024
  53. 1/6 t0080: move expected output to a fileRené Scharfe, Jul 21, 2024
  54. Jeff KingJul 23, 2024
  55. 2/6 unit-tests: add for_testRené Scharfe, Jul 21, 2024
  56. Kyle LippincottJul 22, 2024
  57. Junio C HamanoJul 22, 2024
  58. René ScharfeJul 22, 2024
  59. Junio C HamanoJul 22, 2024
  60. Kyle LippincottJul 22, 2024
  61. René ScharfeJul 23, 2024
  62. unit-tests: show location of checks outside of testsRené Scharfe, Jul 23, 2024
  63. Phillip WoodJul 23, 2024
  64. Kyle LippincottJul 22, 2024
  65. René ScharfeJul 23, 2024
  66. Patrick SteinhardtJul 23, 2024
  67. René ScharfeJul 23, 2024
  68. Patrick SteinhardtJul 23, 2024
  69. René ScharfeJul 23, 2024
  70. Patrick SteinhardtJul 23, 2024
  71. Phillip WoodJul 23, 2024
  72. René ScharfeJul 23, 2024
  73. Phillip WoodJul 23, 2024
  74. Phillip WoodJul 25, 2024
  75. René ScharfeJul 30, 2024
  76. 3/6 t-ctype: use for_testRené Scharfe, Jul 21, 2024
  77. 4/6 t-reftable-basics: use for_testRené Scharfe, Jul 21, 2024
  78. 5/6 t-strvec: use for_testRené Scharfe, Jul 21, 2024
  79. 6/6 t-strbuf: use for_testRené Scharfe, Jul 21, 2024
  80. Phillip WoodJul 23, 2024
  81. 0/7 add and use for_test to simplify testsRené Scharfe, Jul 24, 2024
  82. 1/7 t0080: use here-doc test bodyRené Scharfe, Jul 24, 2024
  83. 2/7 unit-tests: show location of checks outside of testsRené Scharfe, Jul 24, 2024
  84. 3/7 unit-tests: add for_testRené Scharfe, Jul 24, 2024
  85. Kyle LippincottJul 24, 2024
  86. Phillip WoodJul 25, 2024
  87. Junio C HamanoJul 25, 2024
  88. Kyle LippincottJul 25, 2024
  89. Junio C HamanoJul 26, 2024
  90. Patrick SteinhardtJul 26, 2024
  91. Junio C HamanoJul 26, 2024
  92. Patrick SteinhardtJul 29, 2024
  93. Junio C HamanoJul 29, 2024
  94. Patrick SteinhardtJul 30, 2024
  95. René ScharfeJul 30, 2024
  96. Patrick SteinhardtJul 31, 2024
  97. René ScharfeJul 31, 2024
  98. Patrick SteinhardtAug 1, 2024
  99. 4/7 t-ctype: use for_testRené Scharfe, Jul 24, 2024
  100. 5/7 t-reftable-basics: use for_testRené Scharfe, Jul 24, 2024
  101. 6/7 t-strvec: use for_testRené Scharfe, Jul 24, 2024
  102. 7/7 t-strbuf: use for_testRené Scharfe, Jul 24, 2024
  103. 0/6 add and use if_test to simplify testsRené Scharfe, Jul 30, 2024
  104. 1/6 t0080: use here-doc test bodyRené Scharfe, Jul 30, 2024
  105. Kyle LippincottJul 31, 2024
  106. 2/6 unit-tests: show location of checks outside of testsRené Scharfe, Jul 30, 2024
  107. Kyle LippincottJul 31, 2024
  108. René ScharfeAug 1, 2024
  109. 3/6 unit-tests: add if_testRené Scharfe, Jul 30, 2024
  110. Kyle LippincottJul 31, 2024
  111. René ScharfeAug 1, 2024
  112. Kyle LippincottAug 2, 2024
  113. 4/6 t-ctype: use if_testRené Scharfe, Jul 30, 2024
  114. 5/6 t-reftable-basics: use if_testRené Scharfe, Jul 30, 2024
  115. 6/6 t-strvec: use if_testRené Scharfe, Jul 30, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.