Unit tests, asserts and contradictions in the spec

[H. S. Teoh]

On Fri, Feb 08, 2019 at 09:02:02AM +0000, Atila Neves via Digitalmars-d wrote:
> On Thursday, 7 February 2019 at 18:53:22 UTC, H. S. Teoh wrote:
> > On Thu, Feb 07, 2019 at 06:10:58PM +0000, jmh530 via Digitalmars-d
> > wrote:
> > > On Thursday, 7 February 2019 at 15:43:34 UTC, H. S. Teoh wrote:
> > > > [snip]
> > > > Of course, on the flip side, unittests that acquire global /
> > > > external resources that need cleanup, etc., are IMNSHO a code
> > > > smell.
> > > 
> > > That's a good point. I should probably just stick pure on every
> > > unittest block by default.
> > 
> > That's a good ideal to strive for, but then it would preclude
> > testing non-pure functions, which seems rather too limiting to me.
[...]
> When my functions aren't pure I get sad.

It's funny, my default coding style is pure, but I never bothered to
stick 'pure' to my declarations.  I probably should start doing that so
that the compiler can catch any non-pure stuff for me that I overlooked.


> Unfortunately sometimes there's nothing I can do about it because I
> depend on external code that isn't pure itself. But my default for
> unit tests is `@safe pure`.

That's a good practice to have.  But a lot of D code out there in the
wild aren't written this way.


T

-- 
A bend in the road is not the end of the road unless you fail to make the turn. -- Brian White