Do everything in Java…

[deadalnix via Digitalmars-d]

On Friday, 5 December 2014 at 15:55:23 UTC, Chris wrote:
> Everywhere? For each function? It may be desirable but hard to 
> maintain. Also, unit tests break when you change the behavior 
> of a function, then you have to redesign the unit test for this 
> particular function. I prefer unit tests for bigger chunks.
>

If the change is voluntary, you don't only need to change the
test, but all callsites. You are lucky that the unit test warned
you about this !

>> but I find the real gains come from being able to verify the 
>> behaviour of edge cases and pathological input; and, 
>> critically, ensuring that that behaviour doesn't change as you 
>> refactor.  (My day job involves writing and maintaining legacy 
>> network libraries and parsers in pure C.  D's clean and easy 
>> unit tests would be a godsend for me.)
>>
>> -Wyatt
>
> True, true. Unfortunately, the edge cases are usually spotted 
> when using the software, not in unit tests. They can be 
> included later, but new pathological input keeps coming up 
> (especially if you write for third party software).
>

This is where a test culture plays. It is hard to retrofit
testing in bad design (and it is why it is advised to dev test
along side with the code itself).