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).
* 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.
--
/Jacob Carlborg
