On Wednesday, 1 April 2015 at 18:04:31 UTC, Ary Borenszweig wrote:
On Monday, 30 March 2015 at 22:20:08 UTC, Andrei Alexandrescu
wrote:
This is a tooling issue.
I think D's built-in "unittest" blocks are a mistake.
Yes, they are simple and for simple functions and algorithms
they
work pretty well.
However, when you have a big complex project you start having
other needs:
1. Named unit-tests, so you can better find what failed
2. Better error messages for assertions
3. Better output to rerun failed tests
4. Setup and teardown hooks
5. Different outputs depending on use case
Everything you propose can be done with a custom unittest runner,
using the builtin unittest blocks. Compile-time reflection + UDAs
+ unittests is a surprisingly powerful combination, and I don't
understand the proposals to make unittest name and such part of
the ModuleInfo or provide special compiler support for them. Such
an approach is not as scalable, and with compile-time reflection
you can do anything you need with the current built-in unittest
blocks.
The only issue I have with the way unittests are done right now,
is the incredibly annoying requirement of having a main function
and that main gets called. It makes generic tooling and CI
systems much more annoying, as you have to try and guess whether
you need to create a fake main() (or pass in -main), and worry
about if the code is going to keep running after tests complete.
