4

I'm working on a Perl module that has a lot of XS code and also uses Dist::Zilla to manage packaging. What's the best way to test things efficiently? I know about dzil test, but that's pretty slow because it does a full build/compile/test cycle every time it's invoked.

It would be nice to only update the parts that need updating since last test, and also to be able to run only certain t/*.t test scripts rather than all of them. Anyone have a solution that they like?

Ken Williams
  • 22,756
  • 10
  • 85
  • 147

3 Answers3

2

I have, in the past, just taken a Build.PL/Makefile.PL as generated by dzil and dropped it into the source repository as a "Makefile_dev.PL" (or "Build_dev.PL"), added it to MANIFEST.SKIP (or the dzil-based, generated equivalent) and used it during development.

tsee
  • 5,034
  • 1
  • 19
  • 27
1

For my XS modules, I use either MakeMaker::Custom or ModuleBuild::Custom (both by me). If you set things up properly, you can run Makefile.PL or Build.PL directly in your repo without invoking dzil at all. To run specific tests, you just build the dist and use prove -b testname.

Some examples using ModuleBuild::Custom: Media-LibMTP-API, Win32-IPC.

An example using MakeMaker::Custom: Win32-Setupsup.

cjm
  • 61,471
  • 9
  • 126
  • 175
1

I know I'm pigeonholing myself as old-school, but its for these very reasons that I don't use Dist::Zilla: when it works its great, when it doesn't it can be really hard to make it do what you want.

I guess that means, my answer is: when it gets too hard, just move to one of the primary tools that dzil generates, ie. EUMM or MB directly.

Joel Berger
  • 20,180
  • 5
  • 49
  • 104
  • Yeah, I hear you. Still not going to give it up though. =) It just surprises me there's no ready-built solution to the testing thing though. – Ken Williams May 09 '13 at 12:59