I've just noticed I didn't reply to this. Sorry for the delay.
On Wed, Feb 12, 2014 at 10:53:22AM +0100, Jens Rehsack wrote:
> Am 12.02.2014 um 10:39 schrieb Tim Bunce <tim.bu...@pobox.com>:
> >
> >> 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.
The template data (payload) is cloned for each provider, so changes only
affect the scope of the current provider call (and lower level providers).
https://github.com/perl5-dbi/DBI-Test/blob/master/sandbox/tim/lib/Data/Tumbler.pm#L111
You can see the effect by running tumbler.pl. The
".../plugin/ExampleExtraTests.t"
added by dbd_dbm_settings_provider is only present in the ".../DBM/..." tree.
https://github.com/perl5-dbi/DBI-Test/blob/master/sandbox/tim/tumbler.pl#L356
I hope that addresses your concern about the risk of spaghetti.
> See how first shot of moox_cooperations fails on a similar approach (for
> reasons!),
> while trying to building the bridge to MooX::Options.
I'm not sure what you mean here Jens.
> >> 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 ^^).
Adding threads support wasn't too hard. It just creates a modified
version of all the current settings, adding threads to them, and then
adds them into the current settings.
https://github.com/perl5-dbi/DBI-Test/blob/master/sandbox/tim/tumbler.pl#L156
Some kind of utility function to help with that kind of thing would be useful.
> >> 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.
Ordering is an interesting issue and something I'd not given much though
to until I added support for threads - which should be loaded before any
other modules.
Settings in a context are output in reverse order, just like calling
$context->get_env_var($name) searches backwards. Which is why the thread
example at the link above adds the $thread_setting after the current setting.
> Conceptual we should have an abstraction here, too. It appears inconsistent
> (to me)
> otherwise ...
The Context module would benefit from some polish, like Data::Tumbler has.
> > 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.
If that's the best fit for your needs. You can probably simply use
$payload as the hash.
I've tried out your tumpler.pl and I think I see the problem you're having.
Your providers are oo_implementations (Moose/Moo/etc) first and then
moox_cooperations second. But because Tumbler only 'appends' to the
Context and the Context is output 'backwards', the generated test
loads your MooX::Options module before the Moose/Moo module.
Is that a good summary of the problem?
If so I'll give some though to finding a neat solution.
Tim.
