Calvin Wan wrote: > On Thu, Apr 27, 2023 at 1:15 PM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: > > > > Hi Calvin > > > > On 27/04/2023 18:50, Calvin Wan wrote: > > > Introduces the C TAP harness from https://github.com/rra/c-tap-harness/ > > > > > > There is also more complete documentation at > > > https://www.eyrie.org/~eagle/software/c-tap-harness/ > > > > I'm afraid this reply is rather briefer than I'd like but I'm short of > > time and about to go off-list for a couple of weeks. My ideal unit test > > library would > > - allow named tests (this maybe more trouble that it is worth as I > > think it inevitably leads to more boilerplate code calling the named > > tests) > > I'm not quite sure what you're referring to with "named tests". Could > you clarify (possibly with an example)? Many test frameworks have a way of specifying a name for a test case, for example in JavaScript's QUnit: test('basic test case', t => { t.is('actual', 'expected'); }); In this case "basic test case" is the name of the test case. In git's testing framework: test_expect_success 'basic test case' ' echo actual > actual && echo expected > expected && test_cmp actual expected ' When running this test case the TAP output would be: ok 1 - basic test case Other testing frameworks report on a per-assertion basis, for example Perl's Test::More: is('actual', 'expected', 'assertion check'); These are more like named assertions rather than named test cases. The example of what you proposed shows: ok(unit_test(), "unit test runs successfully"); Which is similar to Test::More, so it seems it runs on a concept of assertions rather than test cases. That's what I presume Phillip meant. Cheers. -- Felipe Contreras
