Re: Tests needing user parameters
On Wed, 19 Oct 2005, Ken Williams wrote: On Oct 19, 2005, at 4:50 PM, Jess Robinson wrote: My module will login to a web service and manipulate data programmatically.. Nothing critical I assure you, just a tool ;) Since theres no dummy/test account that I know of, I'll need the users account/email address and password to login. Typically you'd add some code to the Makefile.PL or Build.PL that asks the user for a username/password to use for testing, and gives the user an option to skip those tests. DBI modules often do this, for example (where the username/password is for a database to access). If you're using ExtUtils::MakeMaker, you'll have to find some file to stash the information, probably somewhere in t/ . If you're using Module::Build, have a look at the notes() method, which is for caching this kind of information. Right, I'd seen a few modules do this, but.. Is there a *standard* way of doing it? Those Makefile.PLs tend to look cluttered and confusing IMO.. a nice: use Test::Auth; get_user_fields(user, password); would be preferable.. (hmmm, could write something that does that, using IO::Prompt.. anyone interested?) Jess
Re: Tests needing user parameters
On Wed, 19 Oct 2005, Spencer Ogden wrote: Requiring user input for testing is probably not a good idea. All of the sudden you now have to validate the input data as well before you can test your own code. Then you need to test you validation code, etc. This article may suggest a solution: http://www.perl.com/pub/a/2005/04/07/mockobject_kata.html Just fake it. Thanks for the suggestion, but consider also: The whole mock object thing would also need a thorough testing itself, making it even more complex. Also, supposing the site that I am connecting to changed their responses, I'd never know, since I'm only testing against a mock-up of it. I'd agree if the thing I was connecting to was under my control, but it isn't. Jess
Re: Tests needing user parameters
Jess Robinson wrote: On Wed, 19 Oct 2005, Ken Williams wrote: On Oct 19, 2005, at 4:50 PM, Jess Robinson wrote: My module will login to a web service and manipulate data programmatically.. Nothing critical I assure you, just a tool ;) Since theres no dummy/test account that I know of, I'll need the users account/email address and password to login. Typically you'd add some code to the Makefile.PL or Build.PL that asks the user for a username/password to use for testing, and gives the user an option to skip those tests. DBI modules often do this, for example (where the username/password is for a database to access). If you're using ExtUtils::MakeMaker, you'll have to find some file to stash the information, probably somewhere in t/ . If you're using Module::Build, have a look at the notes() method, which is for caching this kind of information. Right, I'd seen a few modules do this, but.. Is there a *standard* way of doing it? Those Makefile.PLs tend to look cluttered and confusing IMO.. a nice: use Test::Auth; get_user_fields(user, password); would be preferable.. (hmmm, could write something that does that, using IO::Prompt.. anyone interested?) If there's a standard way of doing it, it would be really nice that it understood when it was being run in a smoke environment, and asked no questions and used built-in defaults. I haven't had time to look at this issue, but after having been smoking CPAN uploads for a while, I'm astonished at the number of modules that sit hanging on STDIN waiting for input. David Jess -- It's overkill of course, but you can never have too much overkill.
Re: Tests needing user parameters
* David Landgren [EMAIL PROTECTED] [2005-10-20 10:30]:
Jess Robinson wrote:
Right, I'd seen a few modules do this, but.. Is there a
*standard* way of doing it? Those Makefile.PLs tend to look
cluttered and confusing IMO.. a nice:
use Test::Auth;
get_user_fields(user, password);
would be preferable.. (hmmm, could write something that does
that, using IO::Prompt.. anyone interested?)
If there's a standard way of doing it, it would be really nice
that it understood when it was being run in a smoke
environment, and asked no questions and used built-in defaults.
That’s exactly what EU::MM’s prompt() function and
Module::Build’s prompt() method do/are for.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: Tests needing user parameters
On Thu, Oct 20, 2005 at 10:29:10AM +0200, David Landgren wrote: If there's a standard way of doing it, it would be really nice that it understood when it was being run in a smoke environment, and asked no questions and used built-in defaults. May I just add an AOL here? It would be very nice if all modules did the right thing in any batch environment. I run into this problem with cpancover. Generating coverage data for a bunch of modules is trivial compared to the problem of actually installing the things. I haven't had time to look at this issue, but after having been smoking CPAN uploads for a while, I'm astonished at the number of modules that sit hanging on STDIN waiting for input. Yes. And is it one of the Readline modules that sits there on make test waiting for me to type exit, meaning that it takes two nights to generate coverage data rather than one? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Tests needing user parameters
A. Pagaltzis wrote : * David Landgren [EMAIL PROTECTED] [2005-10-20 10:30]: [...] If there's a standard way of doing it, it would be really nice that it understood when it was being run in a smoke environment, and asked no questions and used built-in defaults. That’s exactly what EU::MM’s prompt() function and Module::Build’s prompt() method do/are for. Ha, ++aristotle. I can see I'll be filing bug reports/patches for a while :) David Regards,
Re: Tests needing user parameters
On Thu, 20 Oct 2005, A. Pagaltzis wrote: * David Landgren [EMAIL PROTECTED] [2005-10-20 10:30]: Jess Robinson wrote: Right, I'd seen a few modules do this, but.. Is there a *standard* way of doing it? Those Makefile.PLs tend to look cluttered and confusing IMO.. a nice: use Test::Auth; get_user_fields(user, password); would be preferable.. (hmmm, could write something that does that, using IO::Prompt.. anyone interested?) If there's a standard way of doing it, it would be really nice that it understood when it was being run in a smoke environment, and asked no questions and used built-in defaults. That's exactly what EU::MM's prompt() function and Module::Build's prompt() method do/are for. Thanks, that sounds like what I was looking for! (hmm, assuming I can pass the results on to make test.. I'll have a look) Jess
Re: Tests needing user parameters
Quoting David Landgren [EMAIL PROTECTED]:
A. Pagaltzis wrote :
* David Landgren [EMAIL PROTECTED] [2005-10-20 10:30]:
[...]
If there's a standard way of doing it, it would be really nice
that it understood when it was being run in a smoke
environment, and asked no questions and used built-in defaults.
Thatâs exactly what EU::MMâs prompt() function and
Module::Buildâs prompt() method do/are for.
Ha, ++aristotle. I can see I'll be filing bug reports/patches for a while :)
During cpan smoke testing, if the tester is using CPAN::YACSmoke the environment
variable, $ENV{AUTOMATED_TESTING} is also set to indicate to the author that
smoke testing is being performed.
Barbie
--
Barbie (@missbarbell.co.uk) | Birmingham Perl Mongers user group |
http://birmingham.pm.org/
---
This mail sent through http://www.easynetdial.co.uk
Re: Tests needing user parameters
A. Pagaltzis a écrit : * David Landgren [EMAIL PROTECTED] [2005-10-20 10:30]: [...] If there's a standard way of doing it, it would be really nice that it understood when it was being run in a smoke environment, and asked no questions and used built-in defaults. That’s exactly what EU::MM’s prompt() function and Module::Build’s prompt() method do/are for. Hmmm. I just looked at XML::Twig, because I remember smoking it a few weeks ago and it blocked, asking about whether I wanted to install various doodads. I checked the source this afternoon: http://search.cpan.org/src/MIROD/XML-Twig-3.22/Makefile.PL In which we clearly see that mirod is using EU::MM's prompt() function. So there's something else occurring. Perhpas CPANPLUS so cleverly emulates a real session that EU::MM can't distinguish whether STDIN is attached to a tty or not. Time to go gonzui diving. David
Re: Tests needing user parameters
On Oct 20, 2005, at 6:14 AM, Jess Robinson wrote: On Thu, 20 Oct 2005, A. Pagaltzis wrote: * David Landgren [EMAIL PROTECTED] [2005-10-20 10:30]: Jess Robinson wrote: Right, I'd seen a few modules do this, but.. Is there a *standard* way of doing it? Those Makefile.PLs tend to look cluttered and confusing IMO.. a nice: use Test::Auth; get_user_fields(user, password); would be preferable.. (hmmm, could write something that does that, using IO::Prompt.. anyone interested?) If there's a standard way of doing it, it would be really nice that it understood when it was being run in a smoke environment, and asked no questions and used built-in defaults. That's exactly what EU::MM's prompt() function and Module::Build's prompt() method do/are for. Thanks, that sounds like what I was looking for! Oh yeah, I meant to mention prompt() and y_n() (which is M::B-only) but I forgot. (hmm, assuming I can pass the results on to make test.. I'll have a look) That's what notes() is for. If you don't want to use Module::Build, you'll just have to cobble something together yourself, which is what I was talking about when I said you'd have to write it to a file someplace. -Ken
Re: Tests needing user parameters
On Wed, 2005-10-19 at 21:51 +0100, Jess Robinson wrote: Hey folks, I'm writing a module which will need user account data for it's tests, and I'm wondering if theres a standard way (or module) for doing this.. Else I'll guess I'll look for environment variables and otherwise not test, any ideas? Look at the Tangram test suite in 2.08_05; it asks for information about where to find a database to connect for tests, saves the information to a state file in t/. It also correctly handles the situation where no information is given, by altering the test manifest. It doesn't use ExtUtils::MakeMaker::prompt, though arguably it should. Sam.
