About unittest, test runners and assert libraries

Zardoz luis.panadero at gmail.com
Wed May 12 22:25:00 UTC 2021


On Monday, 10 May 2021 at 19:52:28 UTC, SealabJaster wrote:
> [...]
>
> Imagine a custom array type sort of like this, being tested:
>
> ```d
>     struct MyArray
>     {
>         int length;
>         string get(int index)
>         {
>             assert(index < length, "Index out of bounds.");
>             return "Hello!";
>         }
>     }
>
>     unittest
>     {
>         MyArray array;
>         array.length = 2;
>         assert(array.get(1) == "Hello!"); // Success
>         assert(array.get(2) == "Hello!"); // Assert thrown by 
> MyArray.get
>     }
> ```
>
> My point is, would the assert thrown by `MyArray.get` be 
> considered a test failure, or a programmer error? The test 
> runner wouldn't know since it can't distinguish between the two 
> cases with just `AssertError`.
>
> While the Error classes are for unrecoverable errors 
> (programmer error/bugs), the Exception classes are for known 
> bad-states that can be recovered from. E.g. JSON parsing 
> failure is an Exception, not an Error.
>
> So in general, it just feels more natural to catch an Exception 
> instead of an Error, since catching an Error is bad practice 
> anyway.
>
> If you derive from AssertError, you still need to make your own 
> assert functions/throw it manually, like exceptions, so it 
> isn't really too much different from just handling exceptions 
> instead.
>
> [...]

I see. I will do that Pijamas throw a custom Exception that 
extends from the appropriated exception from the test runner.


More information about the Digitalmars-d mailing list