Strong opinions, weakly held

Why do Ruby developers test?

Giant Robots asks the question, Why Do Rubyists Test So Completely? It’s a good question. Developers on other platforms would benefit greatly from the culture of testing that has been established among Rubyists (and especially Rails developers). They have their own list, and I agree with all of the items on it. I have one reason that I’m surprised they didn’t list.

Rails makes it really easy to start testing. When you generate a new Rails application, it gives you a place to put your tests. When you generate controllers and models, it creates skeletal tests for them. Nobody has to sit and wonder, “What should I be testing.” The framework tells you. So the next step is just to fill in the blanks. Then when you want to run your tests, you just type “rake” in your application directory.

Java has JUnit and all of the IDEs have test runners, but beyond that, you’re on your own. What do you test? How do you organize your tests into suites? How do you run the suites? These are all questions you have to answer before you build a testing regime. Individual unit tests are easy to write, but getting it together to really make a habit of testing is a lot more work than it is with Rails.

And in the PHP world, things are even worse. I have never seen a PHP application with a robust unit test suite, although I’m sure they exist.

The Rails approach makes the biggest difference with people who aren’t already committed to unit testing. If you know the value of testing, you’ll jump through the hoops to set up tests, even if it’s a pain. If you’re not yet convinced, then the extra work required to set up unit testing with other platforms prevents people from getting started. It’s very much the deliberate choices the creators of Rails made to encourage and facilitate testing that explain in large part why testing is such a part of the culture.


  1. I just can’t bring myself to not post this question:

    Have you ever seen a robust PHP application? … I haven’t. And I’m pretty sure that they don’t exist either.

  2. I don’t think that’s quite fair. I have done some PHP work lately that I think stands up pretty well, although it does not have unit tests and I constantly have to beat back the forces of entropy.

  3. FWIW, I think Perl’s testing culture is pretty good too (it is arguably the inspiration for Ruby’s, IMO), and the predominant Perl MVC web app framework (Catalyst) does the same “make test files as part of scaffold generation” trick.

  4. I’ve been spending the better part of this week attempting to wrap my head around the state of testing in PHP, so this question is quite apropos. More so, as the PHP application in question is a port of a Rails app (don’t ask).

    We’ve been handed PHPUnit as the test framework of choice. It’s opinionated, surely (particularly w/r/t OOP vs. procedural code), but having worked with the core Rails testing tools (controller and integration testing in particular), PHPUnit has made a number of dubious choices that stem from being a port of JUnit. Because Rubyists keep trying new things, they’ve managed to disprove a number of assumptions about agile tests (fixtures, again) and have (mostly) moved on.

    As I’ve approached this project, I keep trying to make PHP work like Ruby (a frustrating endeavor) or like Java (possible, but without the power and culture of Spring and Hibernate). I try to approach PHP as PHP and embrace its peculiarities, but it has no true soul.

    My quick summary of the problems testing in PHP:

    • PHP is not inherently testable beyond units
      • specifically, the mix of procedural and OOP styles (often in a single app) make it difficult to create a test framework that meshes effectively
      • for web applications, there are any number of ways to dispatch, the most basic being executing the page (which requires a rather specific environment to be simulated)
      • it is much too easy to intermingle test code with application code, particularly when loading environments and doing initialization
    • PHP culture is broken–PHP coders are often satisfied with the status quo, which prevents them from taking that extra step and evolving from functional to elegant. Ruby has a dozen of testing frameworks as a result of that dissatisfaction–Ruby coders are left with the paralysis of choice (and its corresponding problems). For PHP, this leads to an acceptance that tests are unnecessary.
    • shared infrastructure doesn’t exist (autotest, Rake equivalents)
    • it’s not fun–RSpec, Shoulda, etc. have fluent interfaces that make it easy to focus on what you’re testing

    This all surprises me given the sheer amount of PHP code in the wild. You’d think that some of these problems would have been fixed. Perhaps they have and are stuck behind firewalls or buried within comments in the PHP documentation.

Leave a Reply

Your email address will not be published.


© 2016 rc3.org

Theme by Anders NorenUp ↑