Grant McLean

• Website: grantmclean.vox.com/

Recent Actions

• Commented on Your Test Suite is Broken
  I think it's a bit too black and white to suggest that a test suite that takes too long to run is "broken". If you have a large complex system it's going to take a long time to test. In...
• Commented on What I would change about App::Genpass
  Another cool way for coming up with passwords is to take a line from a song - e.g. "Raindrops keep falling on my head" and use the initial letter of each syllable (perhaps with a bit of L337) as your...
• Commented on Tidy up your CPAN author directory, increase your Schwartz!
  FYI, if you're trying to be inclusive of "southern folks", the word you're looking for is 'autumn' :-) A timely reminder nonetheless....
• Commented on Marketing the Entire Box (including the wrapper)
  Historically the Ruby community did not have anything even remotely resembling CPAN. If someone wrote a great library there was no good way to share it apart from building their own web site. In the Perl world, simply uploading a...
• Commented on Alpha Modules and Perl's use Statement
  I've got to say I don't like this. In the Ruby world 'gems' (like CPAN modules) can be versioned so that you can have multiple versions instaleld and each app loads exactly the version required. The result is a nightmare...
• Commented on Converting Pod to search.cpan style HTML
  The way I deal with reading POD on my development workstation is with Apache2::POD and Firefox bookmark keywords. So for example if I want to read the DBD::Postgres POD, I go to the location bar in Firefox and type: pd...

Comment Threads

• jnareb.openid.pl commented on Your Test Suite is Broken

  Can't developers run tests on their branches (on their machines) before submitting them for inclusion in trunk (master branch)? This should reduce CI failures.

• Ovid commented on Your Test Suite is Broken

  @jnareb: We're already running the tests on our own machines, but when we merge them to trunk (also on our own machines!), we need to run them again before the commit to make sure we don't break trunk. It's the fact that the test suite takes too long to run which makes this the problem.

• mpeters.myopenid.com commented on Your Test Suite is Broken

  I just can't see #3 as so black and white. Yes at my $job we have a large test suite that tests some things that take a long time to run (they even take a long time to run in production, so I don't see why the tests shouldn't emulate what's in production). And yes we use CI to help developers so that they don't have to run the full test suite on each commit.

  There are ways to work around lots of people investigating CI failures. But if you have a really large project that has some things that just take a long time to run, you reach a point where you can't make your tests any faster. …

• Mike Friedman commented on Your Test Suite is Broken

  I think you've got a bit of a chicken-and-egg problem. To make your test suite smaller, the only way to go is to break up the monolithic project into several independent projects, each with their own test suite. You don't re-run the tests on all your CPAN dependencies every time you commit (I hope!) so why run tests on DataBridge for a change to Dynamite? The problem is the tight coupling: you can't separate the dependencies from the code, so you can't separate the test suites. I think that if you want to fix this, at some point there's going to have to be a lot of pain while you take a…

• Ovid commented on Your Test Suite is Broken

  @Mike: we don't want to make our test suite smaller unless we're removing duplicate or useless tests. And I don't believe I said we run the DataBridge tests for Dynamite. DataBridge has a separate set of tests. I wrote "there is only one set of tests" for the shared code (primarily the DBIC layer), not that we're running tests for both projects.

  We want to make our test suite faster, not smaller. That's a different beast entirely. We've identified several more areas we can do this in, but it's honestly hard work.