Re: DBIT prototype - feedback wanted
Any feedback? Any feedback at all? Tim. On Sun, Feb 09, 2014 at 11:18:24PM +, Tim Bunce wrote: > 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? > > Thanks! > > Tim.
Re: DBIT prototype - feedback wanted
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 :
> >
> >> 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.
Re: Request consideration of DBD::Neo4p registration
On 17 February 2014 14:13, Martin J. Evans wrote: > On 17/02/14 12:09, demerphq wrote: >> >> On 11 February 2014 23:37, Martin J. Evans wrote: >>> >>> On 11/02/2014 17:56, demerphq wrote: On 10 February 2014 09:59, Martin J. Evans wrote: > > > On 10/02/14 08:36, Tim Bunce wrote: >> >> >> >> On Mon, Feb 10, 2014 at 12:19:05AM -0500, Mark Jensen wrote: >>> >>> >>> >>> Greetings DBI, I would like to register DBD::Neo4p in DBI with >>> prefix >>> neo_. It provides a DBI wrapper >>> for a REST interface to the Neo4j db. >> >> >> >> >> Done. >> >>> https://metacpan.org/pod/REST::Neo4p >> >> >> >> >> I'd suggest abstracting out the transport interface to allow multiple >> transports. Similar to >> https://metacpan.org/pod/Elasticsearch::Transport > > > > > ++ > > >> That lets you, and others, implement other transport/connection >> modules. >> I mention this because LWP is not the fastest HTTP interface. There >> are >> several transports for Elasticsearch that are significantly faster. >> For example https://metacpan.org/pod/Elasticsearch::Cxn::NetCurl > > > > > We found curl much faster than LWP - see > http://www.martin-evans.me.uk/node/117 for some numbers and a problem I > hit > (and got around) with POSTing in Curl. You might want to check out: http://search.cpan.org/~avar/Hijk-0.12/lib/Hijk.pm Very fast. Yves >>> >>> Thanks Yves, I'll be sure to check that out. I need fast and features are >>> less important to me. >> >> >> Sorry for the noise, but I would love to hear how things worked out for >> you. >> >> Yves >> > > http://www.martin-evans.me.uk/node/169 Cool, thanks. I have sent a mail to the authors about your review. Maybe they will respond with changes to hijk to make it more suitable for you. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
Re: Request consideration of DBD::Neo4p registration
On 17/02/14 12:09, demerphq wrote: On 11 February 2014 23:37, Martin J. Evans wrote: On 11/02/2014 17:56, demerphq wrote: On 10 February 2014 09:59, Martin J. Evans wrote: On 10/02/14 08:36, Tim Bunce wrote: On Mon, Feb 10, 2014 at 12:19:05AM -0500, Mark Jensen wrote: Greetings DBI, I would like to register DBD::Neo4p in DBI with prefix neo_. It provides a DBI wrapper for a REST interface to the Neo4j db. Done. https://metacpan.org/pod/REST::Neo4p I'd suggest abstracting out the transport interface to allow multiple transports. Similar to https://metacpan.org/pod/Elasticsearch::Transport ++ That lets you, and others, implement other transport/connection modules. I mention this because LWP is not the fastest HTTP interface. There are several transports for Elasticsearch that are significantly faster. For example https://metacpan.org/pod/Elasticsearch::Cxn::NetCurl We found curl much faster than LWP - see http://www.martin-evans.me.uk/node/117 for some numbers and a problem I hit (and got around) with POSTing in Curl. You might want to check out: http://search.cpan.org/~avar/Hijk-0.12/lib/Hijk.pm Very fast. Yves Thanks Yves, I'll be sure to check that out. I need fast and features are less important to me. Sorry for the noise, but I would love to hear how things worked out for you. Yves http://www.martin-evans.me.uk/node/169 Martin
Re: Request consideration of DBD::Neo4p registration
On 11 February 2014 23:37, Martin J. Evans wrote: > On 11/02/2014 17:56, demerphq wrote: >> >> On 10 February 2014 09:59, Martin J. Evans wrote: >>> >>> On 10/02/14 08:36, Tim Bunce wrote: On Mon, Feb 10, 2014 at 12:19:05AM -0500, Mark Jensen wrote: > > > Greetings DBI, I would like to register DBD::Neo4p in DBI with > prefix > neo_. It provides a DBI wrapper > for a REST interface to the Neo4j db. Done. > https://metacpan.org/pod/REST::Neo4p I'd suggest abstracting out the transport interface to allow multiple transports. Similar to https://metacpan.org/pod/Elasticsearch::Transport >>> >>> >>> >>> ++ >>> >>> That lets you, and others, implement other transport/connection modules. I mention this because LWP is not the fastest HTTP interface. There are several transports for Elasticsearch that are significantly faster. For example https://metacpan.org/pod/Elasticsearch::Cxn::NetCurl >>> >>> >>> >>> We found curl much faster than LWP - see >>> http://www.martin-evans.me.uk/node/117 for some numbers and a problem I >>> hit >>> (and got around) with POSTing in Curl. >> >> >> You might want to check out: >> >> http://search.cpan.org/~avar/Hijk-0.12/lib/Hijk.pm >> >> Very fast. >> >> Yves >> >> > > Thanks Yves, I'll be sure to check that out. I need fast and features are > less important to me. Sorry for the noise, but I would love to hear how things worked out for you. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
Re: "private" copy of Tumbler/Context
On Mon, Feb 17, 2014 at 07:46:17AM +0100, Jens Rehsack wrote: > Am 16.02.2014 um 16:29 schrieb Tim Bunce : > > > > 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? Oops. Done. Thanks. > > I'm still not very happy about the interface between Data::Tumbler and > > Context, i.e.: [...] > > 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). Tumbler, as an algorithm, is simple and has no coupling to Context. A user shouldn't have to construct an object class just to use it. I've opted to go with making Data::Tumbler a class. > > 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 ;) Cool. Go for it. Tim.
[perl5-dbi/DBI-Test] aaad8f: Update README section about threads, subtests and ...
Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: aaad8f083421518c9a002c9aaa41642a6f6ad87d https://github.com/perl5-dbi/DBI-Test/commit/aaad8f083421518c9a002c9aaa41642a6f6ad87d Author: Tim Bunce Date: 2014-02-12 (Wed, 12 Feb 2014) Changed paths: M sandbox/tim/README.pod Log Message: --- Update README section about threads, subtests and skip_all Commit: 17d47ea4d780ca02c182680481222eb284c973c0 https://github.com/perl5-dbi/DBI-Test/commit/17d47ea4d780ca02c182680481222eb284c973c0 Author: Tim Bunce Date: 2014-02-16 (Sun, 16 Feb 2014) Changed paths: M sandbox/jens/tumbler.pl A sandbox/tim/lib/Data/Tumbler.pm R sandbox/tim/lib/Tumbler.pm M sandbox/tim/tumbler.pl Log Message: --- Move Tumbler to Data::Tumbler and clean up the API slightly. Compare: https://github.com/perl5-dbi/DBI-Test/compare/7a37bff78055...17d47ea4d780
