Am 16.02.2014 um 16:29 schrieb Tim Bunce <[email protected]>:
> 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).
git push eaten by stormy weather?
> 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}),
I still prefer entire OO API (I really like function objects as
C++ provides them, but I think expecting users overload their
classes will be a no-go ^^) - this is one thingie I want to play
with.
> 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);
Objects with an expected role being provided sounds more reasonable
to me. This would also allow to hide implementation details (on
both sides).
> 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?
I would start in the real life (but not doing releases) and see whether it
works as expected or not. I did a minor shot for MooX::Cmd related tests and
I think it can work in a limited environment (MX::Cmd, LMU are such) for
clinical trials ;)
Cheers
--
Jens Rehsack
[email protected]
