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