Lines Matching full:tests
10 used to run the tests (not all modules use Test::Harness but the
22 there's a directory called 't' that contains our tests. Test::Harness
27 provides far more control over which tests are executed, in what
36 so that the tests can find the code they will be testing. If I'm
39 running my tests against the installed version rather than the new
59 If I have failing tests in a test suite that consists of more than
64 I can tell prove just to run the tests that are failing like this:
68 That speeds things up but I have to make a note of which tests are
69 failing and make sure that I run those tests. Instead I can use
70 prove's --state switch and have it keep track of failing tests for
83 its idea of which tests failed:
87 As soon as one of my failing tests passes it will be removed from
88 the list of failed tests. Eventually I fix them all and prove can
89 find no failing tests to run:
91 Files=0, Tests=0, 0 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)
95 the tests that cover that code will fail. I'd like to run the whole
96 test suite but have it prioritize these 'hot' tests. I can tell
101 All the tests will run but those that failed most recently will be
102 run first. If no tests have failed since I started saving state all
103 tests will run in their normal order. This combines full test
107 failed tests first followed by all remaining tests ordered by the
123 If my tests take too long to run I may be able to speed them up by
125 effective if the tests are I/O bound or if I have multiple CPU
126 cores. I tell prove to run my tests in parallel like this:
131 is the maximum number of tests to run in parallel. Sometimes tests
136 tests to work out which of them are trampling on the same resource
142 the others are done. I can use the --state switch to run the tests
147 =head2 Non-Perl Tests
150 for Perl. Just about any language can be used to write tests that
160 The first line is the plan - it specifies the number of tests I'm
162 exit before running all the expected tests. The following lines are
166 tests.
170 I want to write tests in Forth and run them using prove (you can
173 switch to tell prove to run the tests using gforth like this:
177 Alternately, if the language used to write my tests allows a shebang
189 runs correctly along with all my other tests.
196 problem I use the --shuffle and --reverse options to run my tests
220 tests, parse, analyse and present the results. By subclassing
275 Now I can run my tests like this
288 When I run my tests TAP::Harness creates a scheduler
290 tests, an aggregator (TAP::Parser::Aggregator) to collect and analyse
294 If I'm running my tests in parallel there may also be a multiplexer
296 tests to run simultaneously.
299 tests. For each test it creates a new parser (TAP::Parser) which
348 before_runtests About to run tests
349 after_runtests Have run all tests
400 open my $tap, '<', 'tests.tap'