Request for pre-review: std.serialization/orange

[Jonathan M Davis]

On Friday, September 30, 2011 16:25:47 Jacob Carlborg wrote:
> On 2011-09-30 08:39, Jonathan M Davis wrote:
> > On Thursday, September 29, 2011 20:58:30 Jacob Carlborg wrote:
> >> * For the unit tests I've used my own kind of micro unit test
> >> framework
> >> (that is included). Is that something we want to have in general in
> >> Phobos so other modules can take advantage of that? Or should I just
> >> rip
> >> out the framework?
> > 
> > I very much doubt that it would be accepted. assertPred failed to make
> > it in spite of the various benefits that it provided, and a number of
> > folks seem to be against more complicated unit testing features making
> > it into Phobos. Not to mention, there's already some discussion of the
> > unit tests taking too long. We aren't going to want anything that adds
> > yet more overhead.
> 
> That's why I'm asking. BTW, if we had a proper unit test framework it
> could be possible to run a smaller set of unit tests to keep the running
> time down to a minimum (not something my framework can do).

That can be done easily enough with a version block with a version specific to 
running longer or shorter tests. No additional framework is necessary.  Don 
has already brought it up in the Phobos newsgroup, but it's unclear whether 
we're going to do anything about it. The main problem is the compile time, not 
the run time, so it's ultimately a compiler issue. Templates and CTFE in 
particular make the whole thing slower.

> >> * The unit tests are located in its own package, I'm not very happy
> >> about putting the unit tests in the same module as the rest of the
> >> code,
> >> i.e. the serialization module
> > 
> > Well, that's the way that Phobos does it, and it's essentially how D's
> > unit tests are intended to work (though obviously, you can work around
> > that if you really want to). Phobos' makefiles are set up with the idea
> > that each module's unit tests are included in that module. I'm not sure
> > that it's guaranteed that we wouldn't allow the unit tests to be
> > separate, but that's not how any of the other Phobos unit tests works.
> > And personally, I find that the unit tests are far more maintainable
> > when they're right next to the functions that they test.
> > 
> > - Jonathan M Davis
> 
> The thing is that just to do a simple test, like serializing an int, it
> requires some extra code. It's not like calling a single function. It
> requires:
> 
> * Something to serialize
> * A serializer
> * An archive
> * Actually doing the serialization
> * Performing several checks on the serialized data
> 
> BTW I don't think it scales to have the unit tests in the same module if
> you want to perform extensive unit tests or if it's a complicated module.
> 
> The unit test code should be equally well organized, readable and
> maintainable as the regular code. I think keeping it in the same module
> makes that harder.s

In my experience, it's _much_ easier to have the tests right next to what 
they're testing. I've found it _very_ annoying when I've had to put unit tests 
after a templated type, because the unit tests coludn't be _in_ the templated 
type where they would be instantiated with it. The Interval unit tests in 
std.datetime are way less manageable because of that.

Now, if you have unit testing each function individually doesn't work very 
well, and if you have to do a bunch of setup for any testing, then the 
situation is a bit different, but you could probably just stick all of the 
tests at the end of the file then, where they're then separate from the code.

- Jonathan M Davis