DMD unittest fail reporting…

[Russel Winder via Digitalmars-d]

On Sat, 2015-12-05 at 10:24 +0100, Jacob Carlborg via Digitalmars-d
wrote:
> […]
> 
> You don't want a stack trace for a failed unit test? I have never
> used a 
> unit test framework that don't output the stack trace for a failed
> unit 
> test. Why would you want that?

I put it the other way round: why do you want a stack trace from a
failure of a unit test? The stack trace tells you nothing about the
code under test that the test doesn't already tell you. All you need to
know is which tests failed and why. This of course requires power
asserts or horrible things like assertEqual and the like to know the
state that caused the assertion fail. For me, PyTest is the model
system here, along with Spock, and ScalaTest. Perhaps also Catch.

Just because some unittests have done something in the past doesn't
mean it is the right thing to do. The question is what does the
programmer need for the task at hand. Stack traces add nothing useful
to the analysis of the test pass or fail.

I will be looking at dunit, specd and dcheck. The current hypothesis is
though that the built in unit test is not as good as it needs to be, or
at least could be. However if instead of assert which is a terminating
assertion, the system did what the Go system does and just has a way of
collected test fail messages, things would be a lot better.  This might
be a non-breaking change if implemented properly.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20151205/2b4516a1/attachment.sig>