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.