Lines Matching refs:you
112 B<STOP!> If you're just getting started writing tests, have a look at
114 which you can switch to once you get the hang of basic testing.
119 data structures. While you can do almost anything with a simple
125 Before anything else, you need a testing plan. This basically declares
129 The preferred way to do this is to declare a plan when you C<use Test::More>.
133 There are rare cases when you will not know beforehand how many tests
134 your script is going to run. In this case, you can declare that you
142 In some cases, you'll want to completely skip an entire testing script.
146 Your script will declare a skip with the reason why you skipped and
150 If you want to control what functions Test::More will export, you
152 but 'fail', you'd do:
156 Alternatively, you can use the plan() function. Useful for when you
228 largely done automatically for you. However, it's often very useful to
229 assign a name to each test. Which would you rather see:
241 The later gives you some idea of what failed. It also makes it easier
246 suggested that you use it.
249 =head2 I'm ok, you're not ok.
322 cannot know what you are testing for (beyond the name), but is() and
336 So you can figure out what went wrong without rerunning the test.
420 Halfway between ok() and is() lies cmp_ok(). This allows you to
433 Its advantage over ok() is when the test fails you'll know what $this
442 It's also useful in those cases where you are comparing numbers and
474 No matter how many @methods you check, a single can_ok() call counts
475 as one test. If you desire otherwise, use:
523 where you'd otherwise have to write
535 you'd like them to be more specific, you can supply an $object_name
599 Sometimes you just want to say that the tests have passed. Usually
600 the case is you've got some complicated condition that is difficult to
601 wedge into an ok(). In this case, you can simply use pass() (to
621 If you pick the right test function, you'll usually get a good idea of
623 that way. So here we have ways for you to write your own diagnostic
652 if you have diagnostics for personal testing but then wish to make
657 changing, but it is guaranteed that whatever you throw at it it won't
672 You usually want to test if the module you're testing loads ok, rather
684 happened ok. It's recommended that you run use_ok() inside a BEGIN
710 because the notion of "compile-time" is relative. Instead, you want:
822 just show you...
862 program, or for which you don't yet have code written. For that you
895 Declares a block of tests you expect to fail and $why. Perhaps it's
896 because you haven't fixed a bug or haven't finished a new feature:
913 You then know the thing you had todo is done and can remove the
918 how much work is left to be done, you're aware of what bugs there are,
919 and you'll know immediately when they're fixed.
937 you'll know when they start passing. Sometimes this isn't possible.
940 cases you have no choice but to skip over the broken tests entirely.
971 you need an Internet connection and one isn't available.
974 is for any code you haven't written yet, or bugs you have yet to fix,
982 Not everything is a simple eq check or regex. There are times you
1011 is_deeply() takes two or three args, you gave %d.
1012 This usually means you passed an array or hash instead
1337 If you simply want to do a little tweaking of how the tests behave,
1338 you can access the underlying Test::Builder object like so:
1346 Returns the Test::Builder object underlying Test::More for you to play
1362 you run less (or more) tests than you planned, the missing (or extras)
1374 If you fail more than 254 tests, it will be reported as 254.
1418 you're going to distribute tests that use no_plan or todo your
1420 CPAN. If you avoid no_plan and TODO tests, the stock Test::Harness
1445 L<Test::Simple> if all this confuses you and you just want to write
1460 L<Test::Deep> gives you more powerful complex data structure testing.
1486 This program is free software; you can redistribute it and/or