There is a team working on acceptance testing X11 GUI application in our company, and they created a monstrous acceptance testing framework that drives the GUI as well as running scenarios.
The framework is written using Perl 5, and scenario files look more like very complex Perl programs (thousands of lines long with procedural-programming style) than acceptance tests.
I recently learned Ruby's Cucumber, and generally have been using Ruby for quite a lot of time. But unfortunately I can't just shove Ruby to replace Perl because the people who are writing all of this don't know Ruby and it's quite certain that they wont want "this" kind of interruption.
So to bring Ruby's Cucumber a bit closer to their work, I rewrote it using Perl 5. Unfortunately I am really not a Perl programmer, and would love to get a code review and to hear suggestions from people who both know Perl and Cucumber.
Hi Perl/Cucumber StackOverflow users - please help me create this "open source" attempt to re-create Cucumber for Perl! I would love to hear your comments and will accept any acceptable help.
The minimal source code is here:
http://github.com/kesor/p5-cucumber
Thank you for your attention.
For those not familiar with cucumber - please take just one small moment to take a look at this one small little page: http://cukes.info/
You might get good help on Perlmonks. That site is geared toward this sort of post, whereas Stackoverflow is more about direct and answerable questions.
Good luck, :)
There's a rather fuller implementation of Cucumber on Perl in the form of Test::BDD::Cucumber.
Can you review my Perl rewrite of
Cucumber?
Answer: Yes.
I've read through the github code you posted. It looks pretty good.
I'm curious about the following snippet from Parser::Parser.yp::ERROR. Why did you chose to use "and do {}" over "if( ){ }"? Style? scoping? other?
exists $parser->YYData->{ERRMSG}
and do {
print $parser->YYData->{ERRMSG};
delete $parser->YYData->{ERRMSG};
return;
};
I haven't used cucumber and am still trying to wrap my head around the usage model. How would someone go about verifying/running your calculator example?
If you plan to release your code to CPAN (and you should), then you'll want to bundle this git source into an installable tarball. You'll want to include one of the module installing tools: ExtUtils::MakeMaker, Module::Build, etc. I've recently started using Dist::Zilla, and am really happy with it. It got me over the activation energy of releasing my first cpan module.
20 second tour of Dist::Zilla:
download and install Dist::Zilla
and its requirements (there are
many, as it's a developer only tool)
create a dist.ini file in the top
level of your package ( 'dzil new MyPackage' )
run
'dzil test', 'dzil build', and 'dzil
release',to test, (build and test),
(build, test and release)
See the Dist::Zilla::Tutorial
Does Test::A8N fit your requirement?
If not there are plenty of other Test:: modules on CPAN which may do what you're after.
Related
Right now, I have my own homegrown testing harness/directory structure/support doc strucure/distribution tools for my libraries. However, reading the blog post Write your code like it's going on CPAN, it sounded like a good idea. Then it occurred to me, I'm really not sure how to do that.
What are some good resources to get started making your own Perl packages in the CPAN-like structure?
I usually start with Module::Starter. It comes with a pretty simple command-line tool that will create a new distribution from a template, including all the necessary files and a t/ directory, and so on. It will also produce either a Makefile.PL (using ExtUtils::MakeMaker) or a Build.PL (using Module::Build.)
It also places an empty .pm file there with templates in place for your POD and such.
The best place to start is the CPAN FAQ.
As noted there, the following are good resources:
perldoc perlmod
perldoc perlmodlib
As always, the PerlMonks are a good resource as well. See their "How to make a CPAN Module Distribution".
Ricardo Signes is a pretty prolific module author, and he often writes tools to make module creating as easy as possible. His modules are usually pretty up to date and he seems to stick with the most modern approaches to creating a CPAN distribution, so his distributions are probably good examples. He seems to use Dist::Zilla for managing and uploading his distributions.
Check out Module::Starter module which generates useful boilerplate to help with the creation of a modern Perl module.
Write tests! Check out the Perl Quality Assurance Projects page. It's a bit outdated, but it has some great links to quality reading material.
Check out CPANTS, the CPAN Testing Service
After you've read up on the best tools to create modules, get an account on PAUSE, which allows you to manage your distributions on the CPAN.
Join the #perl IRC chat channel on irc.perl.org. Only about half of the discussion is actually about Perl, but a lot of module authors hang out there and you can learn a lot.
See José's Guide for creating modules.
You might also like Sam Tregar's Writing Perl Modules for CPAN.
I've found a lot of threads around this question here at stackoverflow. They are 2 years old now. So I would like to know if someone is using scottmuc functions to perform a BDD in powershell. It seems very powerful at first sight.
What's your opinion about? Somebody knows some other well effective BDD framework? I would like something really close to rspec.
Note I need BDD not TDD (PSUnit) suggestions/indications.
No many using BDD on powershell then, seen the answers :). Does it mean that BDD is not useful at all, only because powershell is just scripting? I don't think it's a valid reason.
Anyway here the list up to now:
Pester, much more close to something like rspec
PowerSpec, is seems just a few should
I'm the author of Pester and happy to see that you found it! Pester was created to surround another project I did called PowerYaml (as well as the stuff #manojlds mentioned). I wanted to refactor it, but without test coverage, I didn't feel comfortable doing that. So Pester was born, and PowerYaml got refactored. It might be a decent example to show a real world situation where it is useful.
Secondly, I've just recently published a blog post that my shed some light on how to use Pester and it's workflow.
Hope this helps. If you have feature requests, please submit them to the github project.
We are using Pester in our project. It serves our purpose and we are trying to improve upon it. And yeah, the author is my colleague and wrote it for the project.
There is also PowerSpec - https://github.com/shishkin/PowerSpec ( though the description says it is aimed at TDD with Powershell )
I have recently started working with Perl. Googling reveals a number of editors but I am unable to find an editor that will help me navigate a large body of Perl source code. One of the features that I am looking for is the ability of the IDE to integrate with different modules and allow me to jump from one to another. If possible, it will also help if one can see the which function calls what.
I used source insight for C programming and it provides these very useful features. Am looking for similar features in perl.
Help appreciated
Have you looked at Padre? It is a Perl IDE developed by the Perl community.
I'm just giving EPIC a chance.
http://www.epic-ide.org/
Its an Eclipse plugin utilizing a mighty IDE. The advantage I see in using EPIC over Padre is the fact that eclipse can do all sorts of languages and I don't have to get used to multiple different editors every time.
Another great aproach for Perl programming is using emacs. Yes ... its old but I had quite some joy while getting into Perl.
cu
Roman
Komodo IDE, from Active State is also quite good. I haven't used any other Perl IDEs so cannot make comparisons. Most of the features that you are looking for I believe are available in Komodo.
On a side note: The feature that I most appreciated in Komodo was visual debugging.
I mainly use jEdit for Perl programming.
The PerlSideKick plugin, allows you to navigate huge Perl modules (mainly just a plugin for the SideKick plugin).
But there's not much to give you that easy Shift+click navigation you get from Eclipse. jEdit is 100% programmable through Beanshell macros (and JavaScript and Python and JRuby...). So, you can do some of this yourself. So there would be work involved.
For example, it been close enough for me to create "Selection macros" that will allow certain actions on the package or name either highlighted or at the caret. For example, open up the module indicated by the package name.
The Navigator plugin will at least remember where you were last across files.
You might be able to do cross-module navigation through one of the tags plugins
So this won't get you all the way you'd want to go, but it will get you some of the way, and for $0.
It has the most configurable source highlighting this side of writing Emacs-LISP.
It does FTP and remote editing cleaner than most editors I've used.
You can build up a library of Beanshell (shorthand Java) scripts that really help you get what you want done.
Just remember that this recommendation comes with caveats. I have found EPIC quite sub-standard for my use.
I have read, at various times, both the documentation and a number of blog posts on Dist::Zilla. I have never felt confidence in my understanding of it.
In response to another question, #Ether raised the possibility of converting Crypt-SSLeay to use Dist::Zilla.
So, where can I find a concise guide showing me how to convert an existing CPAN module to use Dist::Zilla? Does the question even make sense?
Update:
The Makefile.PL for Crypt-SSLeay does a lot of work (a lot of it seems unnecessary and I am trying to prune it) to find platform specific include and lib directories, to deduce the version of OpenSSL on the machine where it is being installed. How can I include that functionality if I use Dist::Zilla?
The Dist::Zilla Choose Your Own Tutorial has a page on Converting a Dist to Dist::Zilla. One thing it doesn't mention there is my VersionFromModule plugin, which is useful if you want to replicate the way many people use MakeMaker, with the distribution taking its version number from the main module. (Many people use dzil the other way, with the version in dist.ini and a plugin to stick it into the module, but either way works.)
If I need a more complex Makefile.PL than the one dzil generates, I switch to Module::Build and use my ModuleBuild::Custom plugin, which lets me write my own Build.PL and have dzil drop in metadata like the prerequisites.
The MakeMaker::Awesome plugin lets you do something similar with Makefile.PL, but it wasn't quite what I wanted. Instead, I wrote a MakeMaker::Custom plugin that works much like my ModuleBuild::Custom plugin. The big advantage of
MakeMaker::Custom over MakeMaker::Awesome is that it makes it possible to build your dist for testing purposes without having to do dzil build. For an XS module that has to be rebuilt after every minor change, this is a big win.
These are the sites I have found the most helpful so far, as I'm in the middle of converting a CPAN distribution I comaintain to use it, as a learning exercise. I'm not there yet, but I haven't hit any super tricky bits so far!
The official Dist::Zilla site's Choose your own tutorial's guide to Converting an existing distribution
CPAN Dist::Zilla::Tutorial
Dave Golden's Why I'm using Dist::Zilla
Also, the #toolchain and #distzilla channels on irc.perl.org are full of helpful people, including the authors for Dist::Zilla and other related tools.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What's the best framework for writing modules -- ExtUtils::MakeMaker (h2xs) or Module::Build?
NOTE This advice is out of date. Module::Build has been removed from the Perl core but lives on as a CPAN module. The pros and cons still stand, and my opinions about MakeMaker still stand.
As the former maintainer of ExtUtils::MakeMaker, I like to recommend Module::Build because MakeMaker is a horror show. Module::Build is so much better put together. But those aren't your concerns and I'll present my "least hassle for you" answer.
Executive Summary:
Because Module::Build support is not 100% in place through all of Perl, start with MakeMaker. If you want to do any customization at all, switch to Module::Build. Since their basic layout, options and interface are almost identical this will be painless. As seductive as it looks, avoid Module::Install.
Fortunately, Module::Build can emulate MakeMaker which helps some, but doesn't help if you're going to do any customization. See Module::Build::Compat.
For CPAN releases using Module::Build is fine. There's enough Module::Build stuff on CPAN now that everyone's dealt with getting it bootstrapped already.
Finally, the new configure_requires option lets CPAN shells know to install Module::Build before they can start building the module. Unfortunately only the latest CPAN shells know about configure_requires.
Oh, whatever you do don't use h2xs (unless you're writing XS code... and even then think about it).
MakeMaker Pros:
Comes with Perl and used by the Perl core (therefore it is actively
maintained and will remain so forever)
Everything knows what to do with a Makefile.PL.
Most module authoring documentation will cover MakeMaker.
Uses make (those who know make can debug and patch the build
process)
MakeMaker Cons:
Requires make (think Windows)
Difficult to customize
Even harder to customize and make cross platform
Difficult to debug when something goes wrong (unless you understand make)
Module::Build Pros:
Easier to customize/subclass
Pure Perl
Easier to debug (it's Perl)
Can emulate MakeMaker in several ways
The CPAN shell will install Module::Build for you
Module::Build Cons:
The Module::Build maintainers (and indeed all of the Perl Toolchain Gang) hate it
Older versions of CPAN clients (including CPANPLUS) don't know anything about Module::Build.
Module::Install Pros:
Slick interface
Bundles itself, you have a known version
Everything knows how to deal with a Makefile.PL
Module::Install Cons:
Requires make
Always uses bundled version, vulnerable to external breakage
Difficult to customize outside its interface
Mucks with the guts of MakeMaker so a new MakeMaker release will eventually break it.
Does not know how to generate a META file using the v2 meta-spec
(increasingly a problem with newer tools)
There are two questions here.
First, never use h2xs. It's old outdated nastiness, though I suppose if you're actually trying to turn a header file into XS code, it might be useful (never done that myself).
2011 update: I strongly recommend taking a look at Dist::Zilla, especially if you think you'll be maintaining more than one module.
For creating a new module, use Module::Starter. It works great, and has some nice plugins for customizing the output.
Second, you're asking what build system you should use. The three contenders are ExtUtils::MakeMaker (EUMM), Module::Build (MB), and Module::Install (MI).
EUMM is a horrid nasty piece of work, but it works, and if you're not customizing your build process at all, works just fine.
MB is the new kid, and it has its detractors. It's big plus is that if you want to heavily customize your install and build process, it's quite possible to do this sanely (and in a cross-platform manner) using MB. It's really not possible using EUMM.
Finally, MI is basically a declarative wrapper on top of EUMM. It also packages itself along with your distro, in an attempt to work around problems with users trying to install modules with old toolchain modules. The downside of the "package self" trick is that if there's a bug in MI itself, you have to re-release all your modules just to fix it.
As far as customization goes, there are some plugins for MI, but if you want to go beyond them you'll be back at the problem of dealing with Makefiles and build tools across a dozen+ platforms, so it really isn't going to help you too much in that realm.
I just uploaded Distribution::Cooker to CPAN. It's what I use to make new distributions. The nice thing about it is that your distributions can be whatever you like: you're just cooking some templates. I don't care if anyone uses it. For me it's simple, low tech, and doesn't cause extra problems.
You might start with something like Module::Starter to make your starter templates then add your own boilerplate and favorite way of doing things. You choose not only whatever you want in each file, but which files show up in the distro. As you figure out how you like to do things, you simply update your own templates.
As for Makemaker and Module::Build, the future is Module::Build. It's only us old guys using Makemaker anymore. :) There are ways to use both (or pretend to use both) at the same time. Look at the Module::Build, Module::Build::Compat, and Module::Install docs. Module::Build was kicked out of Perl's Standard Library and it's future is uncertain. It's back to Makemaker as a build system.
Although this is a bit of a cop-out answer, try using each just to get a little experience with each.
You also might want to look at Dist-Zilla which is a new author-only tool to create distributions. Because it just helps build the distribution, it doesn't ship with your code or do any installation, it can do a lot of powerful stuff.
The only trouble with compatibility regarding Module::Build is when a user tries to install modules without updating their CPAN client (CPAN.pm or CPANPLUS.pm) If they are installing your module from the CPAN, they can just as easily upgrade their client from the same mirror.
If you don't want to do anything complicated in your build process, sure: use EUMM. But if you have a build problem on a different target platform, you might end up in the Makefile, which is different on every variation of make.
Module::Build gives you lots of features (anything you can think of if you extend it) and is all perl so you never end up debugging a makefile. Module::Install gives you features, but you have to bundle it and everything ends up running through 'make' in the end.
I also recommend Module::Build and Module::Starter (with the TT2 plugin).
Module::Build is better by any means, but it is less widely supported than ExtUtils::MakeMaker (more specifically, older versions of Perl don't support it out of the box). It depends on your needs.
Personally, I recommend Module::Install, as do a lot of folks I know - the likes of the Catalyst and Moose folks also use it.
Here's a little clarification of the direction I hoped the responses would take:
pros/cons of various of frameworks
compatibility/install base of frameworks
suitability for internal (local) vs. external (CPAN) releases
not bare "use X" answers
Dave's answer has some good pro/con info. Leon's answer alludes to compatibility but isn't explicit. As brian d foy mentioned, only the old hats use EUMM, but I'm not convinced that MB is a good framework for things destined for CPAN due to it not being part of the core until 5.9.
There are pros and cons to both. These days I use and recommend Module::Build and Module::Starter.
EU::MM still seems to be the most widely supported and popular one, but Module::Build is catching up. Also, check out Module::Starter for a module that will help you get started.