Am 12.02.2014 um 10:39 schrieb Tim Bunce <tim.bu...@pobox.com>:
> On Wed, Feb 12, 2014 at 09:08:43AM +0100, Jens Rehsack wrote:
>> 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>:
>>
>>> 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.
>
> I'll take a look later.
>
>> 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 ^^)
>
> I'm not sure what you mean here Jens. Perhaps an explicit example of
> what you're concerned about would help.
dbd_dbm_settings_provider modifies *{ $main->{templates} } - if all providers
do that way, we soon have spaghetti DBIT.
See how first shot of moox_cooperations fails on a similar approach (for
reasons!),
while trying to building the bridge to MooX::Options.
>> 4) Probably a sandbox issue: Test::Database requires DBI -> Chicken Egg
>> Problem
>
> I suspect Test::Database will get split into two parts. (All DBIT really
> needs at the moment is a module to read the Test::Database config file.)
/me nods
The DBIT::DSN::Providers were meant as the lower layer part (no DBI
requirement).
Also something like the DBI::Mock might help to decouple (provides only NullP
^^).
>> 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?) ).
>
> Gofer, Multiplex and Proxy are all proxies. I don't see a need to test
> stacking multiple proxies on top of each other.
>
> Beyond that I'm not sure what your concern is here. I don't see any
> problem adding more combinations to the DBI providers. I plan to add
> threads soon, for example.
No problems, it’s just complicated to create the combinations by hand.
The API/Framework shall come with a solution for creating all combinations
and permutations (without repetition) for a given list of provider
representations
(I don’t know how to express it correctly - whiteboard and a lot of pen’s and
arms
would help ^^).
>> 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.
>
> For DBIT I don't see any need to rewrite write_test_file. Is there a need?
I do not see why on one hand we have a very high abstraction (providers) and
on the other hand we simply print out „unmodifiable" order of lines.
Conceptual we should have an abstraction here, too. It appears inconsistent (to
me)
otherwise ...
> For any other use of Tumbler you can write a 'consumer' sub that fits your
> needs.
Which in that case means: deliver another template and other hash with
key/values.
Cheers
--
Jens Rehsack
rehs...@gmail.com
