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
All of this can be done with a library solution. D should have a
very good library solution in phobos and it should be encouraged
to use that. DMD could even know about this library and have
special commands to trigger the tests.
The problem is that you can start with "unittest" blocks, but
then you realize you need more, so what do you do? You combine
both? You can't!
I'd say, deprecate "unittest" and write a good test library. You
can still provide it for backwards compatibility.
By the way, this is the way we do it in Crystal. The source code
for the spec library is here, if you need some inspiration:
https://github.com/manastech/crystal/tree/master/src/spec . It's
just 687 lines long.
I 100% disagree. Having built-in unittest blocks have been a huge
win for the language and greatly improved quality of library
ecosystem. Value of standardization and availability is
tremendous here.
Only problem is that development of the feature has stopped half
way and there are still small bits missing here and there. All
your requested features can be implemented within existing
unittest feature via custom runner - while still running tests
properly with default one!
