Re^5: Building Win32::GuiTest for perl 5.14 or higher (Bad tests!)

Wouldn't it be better to configure the test suite with TODO's, and the incomplete target code with "..." operators instead of polluting the code base with silently-incomplete code?

I do understand your point though. But it's probably more applicable to the development process than it is to a module uploaded for the world to use on CPAN.

Dave

Comment on Re^5: Building Win32::GuiTest for perl 5.14 or higher (Bad tests!) Download Code

Replies are listed 'Best First'.
Re^6: Building Win32::GuiTest for perl 5.14 or higher (Bad tests!) by cavac (Prior) on Jun 25, 2012 at 21:16 UTC
I can agree to that. It really depends if it's mostly an internal process streamlined for fast development (often enough i only have hours to days to come up with a large one-off solution that's running for a limited time and scope). Or if the module is designed for a broad audience. What it comes down to, in my mind at least, is that many of those problems could be avoided by an enhanced, clearer syntax for conditionally specifying modules as optional requirements ("i need that or that, but at least one of them") as well as clearer syntax for conditionaly using them in the scripts (best solution would be "try this list of modules in the given order and load the first one you find and tell me which one it was"). Example: Let's say we have two modules with the same API, but one for Linux/Unix and one for windows, i could them do `my $pwmodule = use_first qw[Linux::Power Win32::Power]; my $power = $pwmodule::new(); $power->suspend();` [download] "You have reached the Monastery. All our helpdesk monks are busy at the moment. Please press "1" to instantly donate 10 currency units for a good cause or press "2" to hang up. Or you can dial "12" to get connected directly to second level support."	[reply] [d/l]

Replies are listed 'Best First'.

Re^6: Building Win32::GuiTest for perl 5.14 or higher (Bad tests!)
by cavac (Prior) on Jun 25, 2012 at 21:16 UTC

I can agree to that. It really depends if it's mostly an internal process streamlined for fast development (often enough i only have hours to days to come up with a large one-off solution that's running for a limited time and scope). Or if the module is designed for a broad audience.

What it comes down to, in my mind at least, is that many of those problems could be avoided by an enhanced, clearer syntax for conditionally specifying modules as optional requirements ("i need that or that, but at least one of them") as well as clearer syntax for conditionaly using them in the scripts (best solution would be "try this list of modules in the given order and load the first one you find and tell me which one it was").

Example: Let's say we have two modules with the same API, but one for Linux/Unix and one for windows, i could them do

my $pwmodule = use_first qw[Linux::Power Win32::Power];
my $power = $pwmodule::new();
$power->suspend();
[download]

"You have reached the Monastery. All our helpdesk monks are busy at the moment. Please press "1" to instantly donate 10 currency units for a good cause or press "2" to hang up. Or you can dial "12" to get connected directly to second level support."

[reply]
[d/l]