Am 29.09.2013 um 21:26 schrieb Tim Bunce <tim.bu...@pobox.com>: > The DBI adopted an approach towards testing 'variants' by creating extra > test files that act as wrappers around existing test files. > > The wrappers modify the process in some way, such as setting environment > variables, before executing the original test file. > > It works well, and the DBIT has adopted the same approach. > > I think the approach is good and more widely applicable than just the DBI. > > I'd like to propose that we factor it out into a separate distribution. > > Thoughts?
I had the same idea - even several separate distributions, but I rejected myself there for following reasons: 1) The variants of the driver result in an n choose k combination 2) The driver attributes (eg. list of dbm backends, list of mldbm serializers) result in a cross product of those vectors. When making separate distributions, 1st approach would be to create a really generic combinatorics distribution. There are some, but all currently have drawbacks. This distribution would likely develop an own life (combinatoric problems tend to become complex and require lot of performance speed ups). Based on that Math::Fast::Combi (*gg*) Test::MakeVariantTesTFiles would require exactly to know what shall be done where. I think - from the current point of view, this would result in an over complex API. Maybe sourcing out the combinatoric algorithms would clean up the code a bit and later when we know better we can additionally create a distributions for computing variants (combinations, variations, permutations, cross products, …) and based on that ? Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org
