xUnit Testing Framework for D

[Mario Kroeplin]

1. assertEquals vs. assertArrayEquals

Currently, the reporting of failures is the main reason for 
having two functions.
For short arrays of short items, the difference looks best using 
'assertEquals'.
With 'assertArrayEquals', you'll only get the index and the first 
mismatch reported.

For multi-line representations, I would wish for something like 
Python's difflib.ndiff in D.

2. assertEventually

I fear, 'assertEventually' was born out of the old-style 
threading where you poll shared memory for the result of an 
asynchronous computation. (In our company, we avoid testing 
asynchronous code in unit tests as much as possible.)

3. ancient history

I would rather call xUnit a proven tool. (As the inventors of 
'Spock' do.)

Still, programmers "in the trenches" often think, that automated 
testing is a waste of time. Do you think, this is due to a flaw 
in xUnit testing? I was still optimistic that in a few years I no 
longer have to explain how to mock objects to test interactions. 
On the other hand, I've yet to see a keyword-driven test for 
complicated features.

4. "required reading"

I'll try and 'Catch' up with 'CUTE' 'Spock'.

My favorite was 'Cucumber'. (In our company, we currently use 
Python's 'unittest'  for integration testing, although we stick 
to the xUnit framework.)

5. wrong name 'dunit'

I could get to like 'detest'. It would match up with 'deject' :-)