Hi all, because I’m a bit overloaded at the moment, please don’t misinterpret following as general reject or blame or something like that.
I waited with the answer until I had time to create an own sandbox and shoot a bit around. Seems now I have some bullet holes :D Am 10.02.2014 um 00:18 schrieb Tim Bunce <tim.bu...@pobox.com>: > As you probably know, I've been hacking on a rough DBI::Test prototype > for a while. My primary goal has been to discover and explore the issues. > Trying to write only the minimum amount of code to do so. > > It's now at the stage where there's something basic working for > all the key aspects... > > Test variant generation > The interface between the generated test script and the input test module > Integration with Test::Database > Fixture provider abstraction > Fixture abstraction, including auto-teardown on DESTROY > Support for unique table names so parallel testing works > > Please take a moment to read this README file: > > https://github.com/perl5-dbi/DBI-Test/blob/master/sandbox/tim/README.pod > > Then, ideally, checkout the repo and play with it. > > Then, please, give me feedback! > > What's good? > What's bad? > What can be done better? > What's missing? > What's are the priorities now? First: I like the general approach of separating of concerns. That’ll allows to reuse the idea of flexible environments. I tried it for my recent problem child MooX::Cmd (and extend some tests to MooX::Options cooperation). In principle, the "MooX::Options cooperation“ test case should be installed to be reused from Vincent when hacking on MX::O ... So far so good - see https://github.com/perl5-dbi/DBI-Test/tree/master/sandbox/jens how I tried to reach those (more or less) simple goals. My current sense of the entire stuff is: 1) I now have a rough intention how all must have felt when seeing my first approach 2) There is one complexity exchanged for another one ==> neither are good 3) To much implicit code - for having a test framework, I would prefer explicit code, especially mix between coderefs (providers) and values (test cases/templates). ==> Maybe having a Class::Tiny based API would improve (lazy attributes ftw ^^) 4) Probably a sandbox issue: Test::Database requires DBI -> Chicken Egg Problem 5) Providers framework need also support for variations, combinations and permutations - mixing gofer+pureperl works only for small lists (add S::S vs. Nano, Gofer vs. DBD::Multiplex vs. DBD::Proxy ... (we don’t want to test Gofer via Multiplex, do we?) ). 6) I didn’t find the time to rewrite „write_test_file“ - but I think a nice template as hacked in https://github.com/i-scream/libstatgrab/blob/master/tests/testlib/mk_run_tests.pl would allow more flexibility. I hope that doesn’t clean up any existing motivation and I really recognize it as a playground. Cheers -- Jens Rehsack rehs...@gmail.com
