toHash => pure, nothrow, const, @safe

[H. S. Teoh]

On Mon, Mar 12, 2012 at 07:41:39PM +0100, Alex Rønne Petersen wrote:
> On 12-03-2012 19:04, H. S. Teoh wrote:
[...]
> >Tangential note: writing unit tests may be tedious, but D's inline
> >unittest syntax has alleviated a large part of that tedium. So much
> >so that I find myself writing as much code in unittests as real code.
> >Which is a good thing, because in the past I'd always been too lazy
> >to write any unittests at all.
[...]
> I stopped writing inline unit tests in larger code bases. If I do
> that, I have to maintain a separate build configuration just for test
> execution, which is not practical. Furthermore, I want to test my code
> in debug and release mode, which... goes against having a test
> configuration.
[...]

Hmm. Sounds like what you want is not really unittests, but global
program startup self-checks. In my mind, unittests is for running
specific checks against specific functions, classes/structs inside a
module. I frequently write lots of unittests that instantiates all sorts
of templates never used by the real program, contrived data objects,
etc., that may potentially have long running times, or creates files in
the working directory or other stuff like that.  IOW, stuff that are not
suitable to be used for release builds at all. It's really more of a way
of forcing the program to refuse to start during development when a code
change breaks the system, so that the developer notices the breakage
immediately. Definitely not for the end-user.

If I wanted release-build self-consistency checking, then yeah, I'd use
a different framework than unittests.

As for build configuration, I've given up on make a decade ago for
something saner, which can handle complicated build options properly.
But that belongs to another topic.


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG