Am 14.01.2014 um 12:13 schrieb Tim Bunce <tim.bu...@pobox.com>: > On Tue, Jan 14, 2014 at 09:23:19AM +0100, Jens Rehsack wrote: >> Hi everyone, > > Hi Jens.
Hi Tim, >> I noticed last Wednesday that there is a lot of confusion what I mean when >> asking for how do we templating in DBI::Test. > > While that's true, I don't think it's the root cause of confusion. > > I think what we really need to discuss are requirements (high-level > use-cases) and the overall structure of "the system“. I didn’t want to talk about the variables used (INIT vs. PRE). I wanted to talk about the way of glueing the components (eg. simple variable expansion from hash vs. real, even simple templating language) > Without people sharing a good understanding of that context it's > hard to have useful discusions about lower-level implementation details. My intension wasn’t to low-level, but it’s difficult to express when you do nothing more than moving bits all the day ;) >> Beside all sides belonging to that question, I only meant the composition of >> the resulting .t file. > > Why do we need "composition of the resulting .t file" with more > functionality than my trivial prototype tumbler.pl does? Because DBI::Test needs DSN (how ever, even if it’s integrated later) and knowledge about managing the test cases. This shouldn’t be done by the current state of tumbler (though separations of concerns idea). > I'm not saying that we don't - I'm just trying to point out that we all > need to be clear about what we're trying to achieve here. And I wanted to get that question answered last week - not the details of the templating. > Step back Jens and paint a bigger picture in enough detail that the need > for templating becomes clear. > > We need to discuss: > where test code comes from, We (more or less) agreed that test code comes from separate test cases, which allows to run the test code several times with different test setups (in DBI::Test case: DBI_PUREPERL, Gofer, Nano vs. S::S, …) - but for showed example of MooX::Cmd before Christmas several runs with Moose, Moo and Mo are wanted. So Tumbler suits the test variant management - but should it also manage test code or not? Design state was: not (we can update that - be should be clear than). > who writes tests, Depends - some are bundled (eg. with DBI::Test - Tumbler will also bundle basic stuff for self-test, DBI will bundle tests which may or may not used for DBD testing, S::S will contribute tests for DBD::DBM etc.), some will be contributed by CPAN. > what kind of scope an individual test file has, At least the scope of the test case. > how they're shipped and installed. Neither nor, they’re generated during build an not installed at all. Test cases can be installed or not - think of „inc/„ dir in distributions. > Should test code be shipped in .t files, .pl files, or .pm files? In pm files > What's the least amount of knowledge that test code needs to work? That had already been discussed and has nothing to do with basic decisions But for all those questions, we initiated the Wednesday session. I’m happy to discuss tasks which are required before we can step to composing test files. Cheers -- Jens Rehsack rehs...@gmail.com
