Unit tests, asserts and contradictions in the spec

[Jonathan M Davis]

On Sunday, February 10, 2019 4:10:58 AM MST Jacob Carlborg via Digitalmars-d 
wrote:
> On 2019-02-08 14:48, Jonathan M Davis wrote:
> > IIRC, the tests
> > for an XML parser at a company that I used to work for built on one
> > another in such a manner so that they didn't have to keep reading or
> > writing the file from scratch.
>
> The parser should be separate from the IO. But I guess you know that :)

I'm certainly not trying to argue that it's best practice to have unittest
blocks that depend on each other, but I am saying that I have seen the
equivalent in other languages in real world code at jobs that I've had. So,
I fully expect that some folks out there are writing unit tests in D where
unittest blocks depend on the state left by previous unittest blocks - be it
the state in memory or what's on disk. So, attempting to run a unittest
block after a previous one failed, to run them in a different order, to run
them in separate threads, to run them in separate processes, or anything
along those lines will likely break actual code (at least as long as we're
talking about how the standard test runner as opposed to someone writing
their code to work with particular test runner that might work differently).
It was code doing something that it arguably shouldn't be doing, but I fully
expect that such code exists - and the odds of it existing increase as D
grows.

And yes, the parser should definitely be separate from the code that does
the actual I/O, but I've seen plenty of code out there that doesn't do that
- especially when it's code written to solve a specific problem for a
specific application rather than being a general purpose solution.

- Jonathan M Davis