On Tuesday, 4 April 2023 at 12:11:28 UTC, Quirin Schroll wrote:`

assertThrows!Exception(expression);

try { expression(); assert(0); } catch (Exception) {}

It's actually already in Phobos:
https://dlang.org/phobos/std_exception.html#.assertThrown

They have been, with the -checkaction=context switch mentioned in this thread.

On Tuesday, 4 April 2023 at 16:01:17 UTC, Adam D Ruppe wrote:

That too. Not massively in love with it for (say) approximately equal testing floats but it's there.

On Tuesday, 4 April 2023 at 18:50:11 UTC, max haughton wrote:

mir.test's shouldApprox [1] handles that

https://github.com/libmir/mir-algorithm/blob/081418a5bb9f22861fc15cbf44045f7aef5c848f/source/mir/test.d#L17

On Friday, 7 April 2023 at 00:58:11 UTC, jmh530 wrote:

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.

On Thursday, 30 March 2023 at 17:01:26 UTC, Dmytro Katyukha wrote:

You can depend on only the assertions dub subpackage, which is tiny, and then use the standard runner from druntime.

That's a dub bug. If a project lists a dependency only in the unittest configuration, it adds it to the transitive list of dependencies, which is obviously nonsense.

And running in threads, and running specific tests, and...

To each their own, I'd use a "proper" library every time because of the developer experience.

None of those are needed if using pytest, which I'd recommend anyone writing Python code to do. One uses the standard Python assert and it prints error messages that make sense. It's magic, and it's magic I'd want for D.

Nearly every test assertion is of equality. It's nice to have the others when needed, but they're not a good 99.9% of the time.

It's definitely an idea.