Scheme portable testing prior art Lassi Kortela (20 Aug 2020 19:00 UTC)
Re: Scheme portable testing prior art Marc Nieper-Wißkirchen (20 Aug 2020 19:09 UTC)
Re: Scheme portable testing prior art Lassi Kortela (20 Aug 2020 19:17 UTC)
Re: Scheme portable testing prior art Marc Nieper-Wißkirchen (20 Aug 2020 19:31 UTC)
Re: Scheme portable testing prior art Per Bothner (20 Aug 2020 20:58 UTC)
Re: Scheme portable testing prior art Per Bothner (20 Aug 2020 21:13 UTC)
Re: Scheme portable testing prior art Alex Shinn (21 Aug 2020 01:54 UTC)
Re: Scheme portable testing prior art Marc Nieper-Wißkirchen (21 Aug 2020 07:52 UTC)
Re: Scheme portable testing prior art Alex Shinn (21 Aug 2020 09:16 UTC)
Re: Scheme portable testing prior art Marc Nieper-Wißkirchen (21 Aug 2020 11:11 UTC)
Re: Scheme portable testing prior art Alex Shinn (21 Aug 2020 13:41 UTC)
Re: Scheme portable testing prior art John Cowan (20 Aug 2020 19:25 UTC)
Re: Scheme portable testing prior art Lassi Kortela (20 Aug 2020 19:39 UTC)
Re: Scheme portable testing prior art Marc Nieper-Wißkirchen (20 Aug 2020 20:04 UTC)
test-error, portability Lassi Kortela (20 Aug 2020 20:41 UTC)
Re: test-error, portability Marc Nieper-Wißkirchen (21 Aug 2020 06:49 UTC)
Re: test-error, portability Per Bothner (21 Aug 2020 13:21 UTC)
Re: test-error, portability Arthur A. Gleckler (21 Aug 2020 18:24 UTC)
Re: test-error, portability John Cowan (21 Aug 2020 21:54 UTC)
Re: test-error, portability Alex Shinn (22 Aug 2020 15:13 UTC)
Re: test-error, portability hga@xxxxxx (23 Aug 2020 21:24 UTC)
Re: test-error, portability John Cowan (23 Aug 2020 21:44 UTC)
Re: test-error, portability Marc Nieper-Wißkirchen (26 Aug 2020 13:45 UTC)
Re: test-error, portability Marc Nieper-Wißkirchen (26 Aug 2020 13:43 UTC)
Re: Scheme portable testing prior art John Cowan (20 Aug 2020 22:05 UTC)
Re: Scheme portable testing prior art Marc Nieper-Wißkirchen (20 Aug 2020 19:56 UTC)
Re: Scheme portable testing prior art Arthur A. Gleckler (20 Aug 2020 22:27 UTC)
Comments on Arthur's test framework Lassi Kortela (22 Aug 2020 08:56 UTC)
Re: Comments on Arthur's test framework Arthur A. Gleckler (22 Aug 2020 21:28 UTC)
Re: Comments on Arthur's test framework John Cowan (22 Aug 2020 22:34 UTC)
Re: Comments on Arthur's test framework Per Bothner (22 Aug 2020 23:45 UTC)
Re: Comments on Arthur's test framework Arthur A. Gleckler (23 Aug 2020 00:21 UTC)
Re: Comments on Arthur's test framework Per Bothner (23 Aug 2020 00:40 UTC)
Re: Comments on Arthur's test framework Arthur A. Gleckler (23 Aug 2020 01:52 UTC)
Re: Scheme portable testing prior art Alex Shinn (27 Aug 2020 05:04 UTC)
Re: Scheme portable testing prior art hga@xxxxxx (21 Aug 2020 16:52 UTC)

Comments on Arthur's test framework Lassi Kortela 22 Aug 2020 08:55 UTC

>   * I use my own test framework, attached, which was inspired by the
>     original version of JUnit. Its important features are:

>   * Every test is lexically enclosed.

What does this mean precisely?

>   * Every test or group of tests has a name.

Testcase names are optional in SRFI 64 and C/C. IIRC group names are
required.

>   * Tests are first-class objects.

This is nice. SRFI 64 uses "test specifiers" to refer to tests, I can't
find objects in the public interface.

Test objects should probably go into a distinct SRFI from the runners
and the definition framework. It could be a test middleware in a similar
vein as WSGI/Rack/Ring are HTTP middleware.

>   * One can run tests in a mode where only failures are reported. This
>     way, one doesn't have to wade through output in order to figure out
>     whether everything passed, or what failed.

Also nice, for the runner.

>   * It's possible to run individual tests or test groups or all defined
>     tests.
>   * Test groups can be defined concisely.

In SRFI 64 and C/C this is `test-group` or `test-begin/test-end`.

>   * Tests only pass if they return the symbol passed. That makes it
>     harder for buggy tests to appear to pass when they actually never ran.

This is completely novel.

>   * The assert macro uses simple heuristics to display the values that
>     were passed to it. This makes it less necessary to have a family of
>     assert macros for different purposes.

>   * There is an assert-signals-condition macro to test that an
>     expression causes a particular condition to be raised.

Similar to test-error in SRFI 64 and C/C.

>   * Failure reports show the captured continuation of the failing test.
>     This continuation can be used with MIT Scheme's debug to walk the
>     stack of the failure, examining variables, etc. This is particularly
>     useful when an unexpected condition is raised during the test.

This is seriously cool. Would be great to have this in a runner.

I think in addition to MIT Scheme, at least Gambit and Chez have a
continuation-aware interactive debugger.