There must be module with test assertions in Phobos

[Dmytro Katyukha]

On Friday, 7 April 2023 at 00:58:11 UTC, jmh530 wrote:
> On Tuesday, 4 April 2023 at 18:50:11 UTC, max haughton wrote:
>> On Tuesday, 4 April 2023 at 16:01:17 UTC, Adam D Ruppe wrote:
>>> On Tuesday, 4 April 2023 at 15:45:55 UTC, max haughton wrote:
>>>> They are redundant but they allow some slightly nicer 
>>>> failure messages upon failure (i.e. assert fail is not very 
>>>> helpful unless you are at one with all the code)
>>>
>>>
>>> I tend to use -checkaction=context together with -unitest...
>>
>> That too. Not massively in love with it for (say) 
>> approximately equal testing floats but it's there.
>
> mir.test's `shouldApprox` [1] handles that
>
> https://github.com/libmir/mir-algorithm/blob/081418a5bb9f22861fc15cbf44045f7aef5c848f/source/mir/test.d#L17

That's why we need to have some list of standard assertions in 
standard library.

Also, about `-checkaction=context`, i just tried to enable it for 
my lib, and get linking errors mentioned in discussion earlier.

And one more note, i think, that compiler switches is last place 
where newcomer will look for better assert output.

Personally, i think, that implementing it in library could be 
much better than, trying to make compiler to show good assert 
messages.

Also, i would like to note, that there could be special (custom) 
assert functions in complex projects, and it would be nice, if 
they could look similar to those, defined in standard library. 
Example of such functions could be mentioned above 
`shouldApprox`, or as real example from other Python project 
`assertSLAControl(request, sla_control_code, field_name, value)`.

And one more reason, why we need library implementation for 
assertions - i think assetions could be used in two different 
cased:
- `assert` expression in the app/lib code.
     - Usually, it could be used to test if program is in correct 
state in runtime, and in case of failure, it is time to start 
debugging.
     - I think, for this case current implementation (especially 
with `-checkaction=context` switch) is good enough.
     - The key point for this type of usage of `assert` expression 
- it have to fail in really rare cases.
- tests... And there are following requirements/wishes for 
assertions used in unittests:
     - Handle special assertions in more readable and less verbose 
way. Examples could be:
         - check if expression throws specified exception 
(optionally with ability to check exception's message via regex)
         - check if float number is approximately equal to 
something
         - comparing lists/arrays/... with ability to print 
different elements (it is not compiler job)
         - comparing strings with pointing to part of string that 
differes (it is not compiler job)
     - Custom assertions
         - framework/project specific assertions should look 
similar to standard assertions to make code more readable.
     - More verbose output needed to unittests.
     - Standard naming scheme for assertions (does not matter what 
we choose as standard but it have to be standatized)


Also, i think, it would be nice to have nicer traceback output in 
general. Just take a look at pythons tracebacks - it is readable 
(comared to D tracebacks).

Well tested app could have more tests (in terms of lines of code) 
then business logic in some cases, thus, i think, it would be 
nice to provide good tools, that will allow to easily conver 
app/lib with tests and support that test suit for long time.