On Sat, Feb 15, 2014 at 12:07:13PM +0100, Jens Rehsack wrote:
> Hi Tim,
>
> I’d like to go one step further with Tumbler and Context.
> For LMU (https://github.com/perl5-utils/List-MoreUtils) and MooX::Cmd
> (https://github.com/Getty/p5-moox-cmd) I’d like to write the
> distributed tests based on a bundled (inc/, not installed etc.) copy
> of Tumbler & Co.
>
> I think, seeing how it behaves in the wild will provide more
> information. Also it allows to prove how good it can be adapted
> (MooX::Test analogous to DBIT, but arranges tests with Mo, Moo, Moops
> and Moose - and maybe for some hard guys, with
> Class::Tiny+Role::Tiny). For LMU I have to test the
> all/any/none/notall with different tests for different implementations
> - but have also to test xs/perl ($ENV{LMU_PP}) and all implementations
> in one import etc. (read: several test plugins parallel with different
> function names to call ...).
>
> What do you think?
Sounds good.
I've renamed Tumbler to Data::Tumbler and polished it up a little
(and made corresponding changes to both our tumbler.pl files).
I'm still not very happy about the interface between Data::Tumbler and
Context, i.e.:
tumbler(
\@remaining_providers,
$consumer,
[ @$path, $name ],
$context->new($context, $variants{$name}), <=== this
$payload,
);
Tumbler shouldn't be coupled to Context at all.
I think that should be either this:
[ @$path, $name ],
[ $context, $variants{$name} ],
or
[ @$path, $name ],
$code_ref->($context, $variants{$name}),
The first means that $context wouldn't be an object any more (though
individual settings would) so instead of calling methods on context,
like $context->get_env_var($name) you'd call functions like
get_env_var_in_context($context, $name);
The second option means passing in an extra code ref into tumbler().
Either as an extra parameter which then has to be passed down through
the recursion, or by making Data::Tumbler be a class that has the code
ref as an attribute.
I'm leaning more towards the second as being an object is likely to have
extra benefits.
Returning to your suggestion of shipping Tumbler and Context a build-time tools
in another module. Yes, that's worth doing.
Note that Tumbler and Context are not directly related to the test
generation use-case. So I think it would be a good idea to create another
module which is aimed directly at supporting test generation and which
uses Tumbler and Context. That module would contain get_input_tests(),
write_test_file(), plus a plugin mechanism (eg for dbd_dbm_settings_provider).
I suggest you start by creating a prototype of that module in
sandbox/tim/lib and use it in sandbox/jens/tumbler.pl. Once you've
something working I'll hack on it and adopt it in my tumbler.pl.
Sound ok?
Tim.
