On Wednesday, 30 April 2014 at 18:04:43 UTC, Atila Neves wrote:
On Wednesday, 30 April 2014 at 17:30:30 UTC, Dicebot wrote:
I believe only missing step right now is propagation of UDA's
to RTInfo when demanded. Everything else can be done as Phobos
solution.
And if requirement to have all modules transitively accessible
from root one is acceptable it can be already done with
http://dlang.org/traits.html#getUnitTests
Simplicity of D unit tests is their best feature.
IMHO this best feature is only useful when writing a small
script-like program. The hassle of using anything more
heavy-duty is likely to make one not want to write tests. The
unittest blocks are simple, and that's good.
But for me I wouldn't (and haven't) use them for "real work".
When tests pass, it doesn't really matter if they were written
with only using assert or what the output was like or any of
those things. But when they fail, I want to:
. Run the failing test(s) in isolation, selecting them on the
command-line by name
. Have tests grouped in categories (I use packages) to run
similar tests together
. Be able to enable debug output that is normally supressed
. Know the name of the test to know which one is failing
. Have meaningful output from the failure without having to
construct said meaningful output myself (assertEquals vs assert)
I don't know about anyone else, but I make my tests fail a lot.
I think this is key difference. For me failing unit test is
always exceptional situation. And if test group is complex enough
to require categorization then either my code is not procedural
enough or module is just too big and needs to be split.
There are of course always some tests with complicated
environment and/or I/O. But those are never unit tests and thus
part of completely different framework.
