Just to pitch a small explanation about what Cucumber is : It was born out of RSpec, the BDD framework, that replaced asserts with should. And what it does it allow to specify XP stories in plain english and then executes them to see that they pass/fail.
If you take a look at http://github.com/kesor/p5-cucumber you see the shortest possible example of that. The full cucumber, which also allows to specify parameters in a table (kind of like FIT/Fitnesse) is being maintained by Aslak Hellesoy and his project's documentation wiki is here: http://wiki.github.com/aslakhellesoy/cucumber As in the original cucumber the ser of this framework can use whatever testing framework he likes. The I would think that the same will apply to what I wrote, if you want to write your tests with Test::Simple or ::More or ::Most or whatever other Test:: framework you like from CPAN then go ahead. The only thing the Cucumber layer adds is a way to organize the code and a way to organize the scenario and then it executes it in this order. It does not really care what kind of testing code you write in there. The main idea is to allow people who don't necessary know a programming language, but who are domain experts for a product, for example marketing or product managers, to write acceptance tests that can later be run in an automatic way. This requires to write the code behind the specification, usually just once, because the code will get executed by matching a line in the story with a regular expression - and it means that the same code can be reused by multiple stories. So even if the product manager wrote a thousand stories - it might mean that only a hundred parsers need to be written in the code. Or even just six :) I think that even though this explanation might not be on-topic for this thread, it is certainly on-topic for this group. Thank you all again for the Test::More/Most/no_plan/defer_plan explanations. I will probably choose More/no_plan for now because it is bundled with perl and will not require users of my small example to install additional modules. - evgeny On Sat, Mar 14, 2009 at 7:57 AM, Michael G Schwern <schw...@pobox.com>wrote: > Let's sum up. > > The "why can't a program count its own tests" page refers to the problem of > counting the tests *without* running the code. > > `use Test::More "no_plan";` is the most used way to run a test without > having > to hard code the number of tests beforehand. > > The test numbering exists to ensure that all your tests run, and in the > right > order. XUnit frameworks don't need to know the number of tests because > they > simply don't have this type of protection. [1] > > `use Test::Most "deferred_plan";` is a safer way to do that. It ensures > your > test runs to completion and it has the option of taking a number of tests. > Sometimes you can calculate the number as you go. > > Test::More is adding this feature, but there's nothing wrong with > Test::Most. > Unlike other testing systems, Perl does not use a single "test framework" > like JUnit or whatever. Most Test:: modules on CPAN will work together. > [2] > You can mix and match. In this sense it kicks the crap out of everyone > else. :) > > Test::More and Test::Harness will see if your test dies or segfaults. > Test::More will see a normal die and Test::Harness will fail any test > script > with a non-zero exit code. > > A human should never be necessary to determine if a test passed or failed. > Humans are bad at rote tasks and reading huge wads of output. They will > eventually tire of the task or simply miss a failure. Also the next human > will not know what to look for. And it kills test automation. You may > wish > to look at http://testers.cpan.org/ to understand the scale of test > automation > we're talking about. > > I have no idea what Cucumber is, but I have no doubt it can be implemented > as > a Perl testing module to work with everything else. It looks like a clever > FIT framework. For the moment using Test::More will work, but eventually > you'll want to switch to Test::Builder. > > > [1] Perl has this because Larry needed it 21 years ago when he came up with > all this, not necessarily because it's important. > > [2] Through the magic of the Test Anything Protocol and Test::Builder. I > happen to have just given a talk about how this all works. > http://schwern.org/talks/TB2.pdf > (Ignore the title, it's not actually about Test::Builder2) > The audio from the meeting should show up here shortly. > http://pdxpm.podasp.com/archive.html > > > -- > 40. I do not have super-powers. > -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army > http://skippyslist.com/list/ >
