Hi Tom, Chris
I want to update you on my progress with Test::mysqld and the modules we've
been discussing, Data::Babel and Class::AutoDB.
1) I started to integrate Test::mysqld into the Class::AutoDB test suite. It's
the right idea; thanks again for the suggestion! The module itself has some
small problems (not exactly bugs, more like mis-features). I will communicate
the issues to the developer in a bug report. To really use the module, I will
need to build a simple wrapper that works around the issues, or get the
developer to fix the problems (with my help if s/he desires), or just
reimplement the bits of the module I actually need.
2) Looking at the test results and test suite for Test::mysqld, I see that it
faced the same problem that got this conversation going, namely, how to tell
the test/installation driver that MySQL is not available and thus it is
impossible to run the tests. The developer adopted a different (better)
solution than I did, but the net effect is similar: when MySQL is not
available, the test suite skips all the important tests and reports PASS even
though the module wasn't actually tested and won't run on the platform in
question. So, even if Test::mysqld installs cleanly, this does not mean that
MySQL is there, and does not obviate the need for my module to check for MySQL.
3) What I ended up doing with Data::Babel (and will do with Class:AutoDB soon)
is to move the check for MySQL into a test script that runs first. If the
script detects that MySQL is unavailable, it reports this to the test driver
using the pragma capability of TAP version 13, and a slightly customized
version of Build::run_tap_harness (included in my distribution) breaks out of
the test suite when it sees this pragma, reporting PASS as the outcome. It
would be far better to report NA or UNKNOWN, but there doesn't seem to be a
documented way to do this. Please correct me if I'm wrong...
The net effect, as with Test::mysqld, is that Data::Babel will install happily
on platforms where it cannot run. This is a complete crock but more satisfying
than the alternative of FAILing everywhere.
I appreciate your help and any suggestions as to better ways of solving the
problem.
All the best,
Nat
On Jul 27, 2013, at 1:33 PM, Nathan (Nat) Goodman wrote:
> Hi Tom
>
> Thanks for pointing me to Test::mysqld. You're right - it's exactly what I
> need! I'll give it a try here and then move it into AutoDB.
>
> You also correctly surmised that both Babel and AutoDB assume it's okay for
> their tests to scribble on a db called 'test'. Test::mysqld is a much better
> solution.
>
> Thanks again,
> Nat
>
> On Jul 27, 2013, at 9:50 AM, Tom Molesworth wrote:
>
>> Hi Nat,
>>
>> On 27/07/13 16:40, Nathan (Nat) Goodman wrote:
>>> Hi Chris
>>>
>>> I'm guessing you made some change because I saw some test reports from you
>>> reporting FAIL and UNKNOWN. I've decided to take a different tack.
>>>
>>> To reiterate what I'm trying to do: The module in question, Data::Babel,
>>> relies heavily on MySQL, and the tests require the ability to create and
>>> drop MySQL databases, tables, etc. The distribution includes a check for
>>> these capabilities. I'm trying to find a clean way to communicate to the
>>> installation driver that the required capabilities are not available. This
>>> is very common. If I simply generate a FAIL under these conditions, the
>>> module will accumulate a large pile of FAIL reports which I deem to be
>>> undesirable.
>>
>> It seems like this would be an ideal candidate for test_requires => {
>> 'Test::mysqld' => 0 }, since if that installs successfully then the mysql
>> basics have already been tested for you. It would also avoid polluting any
>> existing mysql databases (I'm not entirely clear on how
>> Data::Babel/Class::AutoDB select and use a database but a quick glance at
>> tests seems to indicate it's a db called 'test' on the localhost mysql
>> server?).
>>
>> cheers,
>>
>> Tom
>>
>
