Re: DBIT prototype - feedback wanted

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 <[email protected]>:

> 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
[email protected]