This issue usually is encountered when trying to run make test and sees one test fails. The README describes one can run each test individually, didn't clearly specifies how to do so.
make test uses the script called TEST in the test directory (t). To replicate make test of a single file, one would use this script as follows:
[.../perl/t]$ ./perl -I../lib TEST op/array.t
t/op/array ... ok
All tests successful.
Elapsed: 0 sec
u=0.01 s=0.00 cu=0.03 cs=0.02 scripts=1 tests=194
If you want to see the raw output of the test script, you can run perl as follows:
[.../perl/t]$ ./perl -I../lib op/array.t
1..194
ok 1
ok 2
ok 3
...
ok 192 - holes passed to sub do not lose their position (multideref, mg)
ok 193 - holes passed to sub do not lose their position (aelem)
ok 194 - holes passed to sub do not lose their position (aelem, mg)
The above information and more is found in perlhack.
This document explains how Perl development works. It includes details about the Perl 5 Porters email list, the Perl repository, the Perlbug bug tracker, patch guidelines, and commentary on Perl development philosophy.
Note that you need to run make test_prep before the above commands work. (If you've run make test, you've effectively run make test_prep already.)
Run ./perl harness ../foo/boo.t in the t directory, with foo/boo the name of the failing test.
To run a single test script, use perl, or better, prove. Assuming you are in the module's base directory:
prove -lv t/some-test-script.t
This will run the test script against the libraries in ./lib, with fallback to the libraries available to your install of Perl.
If you want to use the build libraries built by make, then this:
prove -bv t/some-test-script.t
Now the test script will be run against the libraries in ./blib, falling back to libraries installed for your Perl.
The test scripts are typically just Perl scripts that live in a t/ or xt/ or some similar path within the distribution's directory structure. So you can also run them just with Perl:
perl -Iblib t/some-test-script.t
But prove produces nicer test summary information and color coding.
That is about as granular as you can get unless tests are written to allow for targeting specific segments within a test script. If you need to target a specific test within a test script you'll usually have to dig into the test code itself.
Related
Are there any concise one-liners for quick serving of pages or directories if no index.html? Something like this:
python3 -m http.server
Couldn't find a Raku one-liner.
Compare Perl ones, taken from https://gist.github.com/willurd/5720255 and https://github.com/imgarylai/awesome-webservers :
plackup -MPlack::App::Directory -e 'Plack::App::Directory->new(root=>".");' -p 8000
perl -MHTTP::Server::Brick -e '$s=HTTP::Server::Brick->new(port=>8000); $s->mount("/"=>{path=>"."}); $s->start'
Install them prior to use (no additional installs with Python):
cpan Plack
cpan HTTP::Server::Brick
Plack pulls in a gajillion of dependencies so I didn't proceed with installation, and HTTP::Server::Brick doesn't install on my machine as its tests fail.
Both Perl and Raku are generally considered to be good in one-liners, and are meant to deliver DWIM:
"try to do the right thing, depending on the context",
"guess ... the result intended when bogus input was provided"
So I'd expect them - especially modern and rich Raku - to provide a webserver one-liner on par in simplicity with Python.
Or have I missed something?
If the feature lacks, is it planned?
If lacks and not-to-be-implemented, why?
I like http_this (https_this is also available).
There's an annoying shortcoming in that it doesn't currently support index.html - but I have a pull request pending to fix that.
On the other hand, these programs rely on Plack, so maybe you'd rather look elsewhere.
Raku Cro needs one line to install:
zef install --/test cro
And then one to setup and run:
cro stub http hello hello && cro run
From https://cro.services/docs/intro/getstarted
Let's say you want to serve all the files in a project subdirectory e.g. hello/httpd, then tweak the standard hello/lib/Routes.pm6 file to this:
1 use Cro::HTTP::Router;
2
3 sub routes() is export {
4 route {
5 get -> *#path {
6 static 'httpd', #path;
7 }
8 }
9 }
cro run looks for file changes and will auto restart the server
index.html works fine
I suggest a symbolic link ln -s if your dir is outside the project tree
Putting aside the webserver portion of your question, Python and Perl differ in their philosophies. Both of them are perfectly fine ways of doing things, and each appeals to a different sort of crowd.
Python is "batteries included", so it's a heavyweight distribution of many things in its standard library. There's more right out of the box, even if you never use most of it.
Perl tries to distribute just enough for you to install the modules that you decide that you need. That way, you can choose something that is fresher or newer than the thing that Perl chose to distribute.
Now, for the webserver, you may like Mojolicious. It's mostly self-contained (or relies on mostly core modules) so it's an easier install. The links you mentioned have Mojolicious::Lite examples.
Not sure if I am explaining this well, but here goes...
I have a perl script/flow that runs various steps. Each step is basically dependent on the output of its previous step in order to run.
For example:
myflow -step1...input is file0, produces file1
myflow -step2...input is file1, produces file2
myflow -stepN...input is fileN-1, produces fileN
Right now users can run myflow -step1 -step2...-stepN to go from start to finish. I would like to somehow have the ability for the user to run myflow -stepN, have myflow check to see which steps need to be run prior to it, and then run stepN. Maybe no steps were run, so myflow -stepN would start from step1 and continue until it finishes stepN or an error occurs. Maybe step1 through step3 ran fine previously, so running -stepN would start from step4. Maybe all steps ran fine, but the user modified/deleted/touched an intermediate file, so running -stepN would detect this and rerun from that previous step.
Is there a cpan module that essentially mimics this make behavior, i.e. given steps, inputs they require, and outputs they produce, create a dependency graph and determine which steps need to be run?
I'm thinking you could use make itself instead of trying to simulate it.
The makefile rules for "building" each fileX "target" from the fileX-1 "source file" would be invoking your script for the respective step.
I'm running into problems testing a new addition to a module. (Specifically - the ~ operator seems to be not working in Math::Complex for this new feature only.) It's too bizarre to be what it appears but the ideal scheme would be to add the -d option on the top line of the .t program.
Well, I was quickly disabused of that idea! It does not invoke the debugger.
If I wanted to use the debugger, I'd need to create an edit of the .t program that:
Uses (the use command) the module directly. not in the form of
BEGIN { use_ok('My::Module') };
Does not "use Test::More;"
A few other edits that cause gluteal pains
The problem with doing that is that any changes I make in the edited test program I still need to transfer back to the true test program use in "make test". Error prone as best.
I am already using "make test TEST_VERBOSE=1" so that my stdio output shows up. But there's GOT to be a simpler way to invoke the debugger on the .t
Thanks for ideas here.
-- JS
use_ok tests are great, but you should have them in test files of their own, not test files that also test other things.
I'm not sure why you would need to avoid Test::More or use_ok to run the debugger, though. What does happen when you try your test directly:
perl -d -Mblib t/yourtestfile.t?
If all else fails, you can try using Enbugger in your test script.
I have a bunch of perl tests:
Functional Tests
Mechanize Tests
Actual Unit Tests, asserting on functions and return values, etc
Tests that involve external Services, like WebServices
DB centric tests
REST tests
I run all of them via prove and theoretically re-arrange them into various directories and run something like find t/ -name '*.t' ! -name '*timeout*' | xargs prove -l, but gets very difficult (and not good engineering) to name tests a particular way, so we can parse them via find.
Is there a way we can pass a wildcard list of tests to prove when we run it via command line?
If not, is there a more sane approach than what we're currently using?
The usual way to to this is via environment variables. The test file checks whether it's supposed to run, and if it's not does a quick skip_all.
For example:
use strict;
use warnings;
use Test::More;
BEGIN {
plan skip_all => "not running extended tests" unless $ENV{EXTENDED_TESTING};
};
# your slow tests here
done_testing();
Now usually that test will be skipped. But if you set the EXTENDED_TESTING environment variable to "1", it will run.
Standard environment variables include EXTENDED_TESTING, RELEASE_TESTING, and NONINTERACTIVE_TESTING. NO_NETWORK_TESTING is also catching on.
There are various modules to automate this such as Test::Is which allows the simpler syntax:
use strict;
use warnings;
use Test::More;
use Test::Is "extended";
# your slow tests here
done_testing();
If you have some other application-specific categories, you'll have to invent some environment variables yourself. If you think they seem generically useful, blog about them, and maybe they'll catch on and become standard environment variables too.
i think i found the answer as Test::Less
Test::Less - Test Categorization and Subset Execution
test-less normally keeps the index file of mappings between tags and test files, in a file called t/Test-Less/index.txt. You can override this with the --file option or the TEST_LESS_INDEX environment variable.
Tags are strings matching /^[\w\-]+$/.
The -list and -prove commands take what is called a tag specification.
A specication is a a list of tags and possibly file names.
test-less -prove foo bar baz
Runs all the foo tests, bar tests and baz tests.
test-less -prove foo,bar,baz
Even after i was able to fix the compile bug in Test::Less, i was still unable to run any tests using Test::Less which has been broken since 2009. So looking at Test::Class might be the answer:
http://search.cpan.org/~ether/Test-Class-0.46/lib/Test/Class.pm
Sometimes you just want to run a single test. Commenting out other tests or writing code to skip them can be a hassle, so you can specify the TEST_METHOD environment variable. The value is expected to be a valid regular expression and, if present, only runs test methods whose names match the regular expression. Startup, setup, teardown and shutdown tests will still be run.
One easy way of doing this is by specifying the environment variable before the runtests method is called.
Running a test named customer_profile:
#! /usr/bin/perl
use Example::Test;
$ENV{TEST_METHOD} = 'customer_profile';
Test::Class->runtests;
Running all tests with customer in their name:
#! /usr/bin/perl
use Example::Test;
$ENV{TEST_METHOD} = '.*customer.*';
Test::Class->runtests;
I'm using TextMate 1.5.10 (Mac OSX 10.7.2) to write a perl modulino application. To verify the functionality, I'm using test scripts designed to be run with the prove command line tool.
An example of the directory structure I'm using looks like this:
text_mate_test/MyModule.pm
text_mate_test/t/001_load_test.t
The 001_load_test.t file looks like this:
#!/usr/bin/perl
use Modern::Perl;
use Test::More;
use MyModule;
my $testObj = new_ok("MyModule", undef, "Initial load test.");
done_testing();
When I run prove or prove -v in the "text_mate_test" directory, everything passes as expected.
I'd like to be able to setup a hotkey in TextMate that allows me to run the test file without having to jump over to the terminal. Currently, if I run "001_load_test.t" directly from inside TextMate with Cmd+R, it chokes saying "Can't locate MyModule.pm in #INC". That's expected since the test script isn't designed to run directly. (I'm still pretty new to writing test files, but I believe that's the proper way to set them up.)
Running off the assumption that I don't want to change the test file itself, is there a way to setup a hotkey so I can run the file accurately from inside TextMate?
I've figured out an even better way to do this.
In the TextMate Bundle Editor (Menubar -> Bundles -> Bundle Editor -> Show Bundle Editor), I've updated the default "Perl -> Run Script" bundle to this:
#!/usr/bin/env ruby
require "#{ENV["TM_SUPPORT_PATH"]}/lib/tm/executor"
require "#{ENV["TM_SUPPORT_PATH"]}/lib/tm/save_current_document"
TextMate.save_current_document
TextMate::Executor.make_project_master_current_document
### If it's a ".t" test script in a "t" directory, run prove
if ( ENV["TM_FILEPATH"] =~ /^.*\/(t\/[^\/]+)$/ )
### Grab the relative file path for more legible output
relative_file_path = $1
### Jump up one directory so prove will work
Dir.chdir("../");
### Call prove with args to run only the file you are working on.
TextMate::Executor.run("prove", :script_args => ["-v", relative_file_path]);
### Otherwise, run with perl
else
TextMate::Executor.run(ENV["TM_PERL"] || "perl", "-I#{ENV["TM_BUNDLE_SUPPORT"]}",
"-Mexception_handler", ENV["TM_FILEPATH"],
:version_args => ["-e", 'printf "Perl v%vd", $^V;'])
end
Here's a screenshot of how it looks in the Bundle Editor.
The benefit of this is that you can use the same hot key (Cmd+r by default) to run your normal scripts with perl and your test scripts with prove.
This is what I was looking for.
UPDATED: When I first developed this, I only had one test script in the "t" directory. I didn't notice until I added other test scripts that the code in the original version of this answer would run prove across all the scripts. Not just the one being worked on. To get back to the expected behavior, I've update the bundle code so that prove will only run on the active script.
I've come up with a solution. Create a new Perl bundle called "Run Script with prove" and associate it with Shift-Cmd-R. The code for the bundle is:
#!/usr/bin/env ruby
require "#{ENV["TM_SUPPORT_PATH"]}/lib/tm/executor"
require "#{ENV["TM_SUPPORT_PATH"]}/lib/tm/save_current_document"
TextMate.save_current_document
TextMate::Executor.make_project_master_current_document
### If it's a ".t" test script in a "t" directory, run prove
if ( ENV["TM_FILEPATH"] =~ /^.*\/(t\/[^\/]+)$/ )
### Use the relative file path for more legible output
relative_file_path = $1
### Jump up one directory so prove will work
Dir.chdir("../");
### Call prove with args to run only the file you are working on.
TextMate::Executor.run("prove", :script_args => ["-v", relative_file_path]);
else
error_string = "This script's filepath doesn't end with /t/.*\.t\n"
error_string += "That is required for the 'Perl -> Run Script with prove' bundle to work.\n"
TextMate::Executor.run("echo", :script_args => [error_string]);
end
Note: This is the results of a bunch of trial and error hacking. I don't know if it's the "right" to do it, but this works for me. Everything but the last two lines is a copy from the original "Run Script" bundle that comes with TextMate. Based on that, it seems like this should be pretty safe.
UPDATE: When I first built this I only had one test file in the "t" directory. When I added more, I discovered that the original version of the bundle was running all the test files. This code represents an update to the expected behavior of only running the test script you working on. Because of the way I ended up doing that, it also became necessary to add in a fallback. If you try to run a script that doesn't match the standard test file path format, it gives an error message.
It will enable the program to find your module if you add
use lib '..';
to the top of your code (before the use MyModule). This will add the text_mate_test directory to #INC and enable Perl to find the module, though you may come across other problems with running the program directly.