Strong opinions, weakly held

Tag: testing

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.

Practicing Test Driven Development

Tim Bray posts on the actual practice of Test Driven Development.

Here’s my thesis: As a profession, we do a lot more software maintenance than we do greenfield development. And it’s at the maintenance end where TDD really pays off. I’m starting to see lapses from the TDD credo as more and more forgivable the closer you are to the beginning of a project. And conversely, entirely abhorrent while in maintenance mode.

I am definitely not an orthodox member of the TDD tribe. I write code before I write the tests. On a good day, I build out the tests and the features simultaneously. On a not so good day, I don’t do as well. But my main goal with TDD is to have a skeleton of tests for every feature so that when bugs crop up, I can add in the tests that confirm the fixes and expand the regression test suite. So I’m on Tim Bray’s side — the key is to have enough tests initially to make writing tests an essential part of your maintenance process.

Links from May 20

Long delayed roundup of links:

Links for March 12th

  • Jon Udell interviews Ward Cunningham about how the Eclipse portal exposes its innter workings by way of reports on test results, and the advantages the resulting transparency provides. Really, really interesting stuff.
  • Bruce Schneier discusses a report on the lack of security in implantable medical devices that provide remote access.
  • Wired Compiler links to Prism, a Firefox add-on that makes it easy to treat Web sites like standalone desktop applications. It provides a lightweight approach to creating apps like Mailplane.
  • The Morning News: Six-Word Reviews of 763 SXSW MP3s by Paul Ford. This is insane, and I mean that in the best possible way.
  • Postalicious is the WordPress plugin I used to produce this post.

© 2023 rc3.org

Theme by Anders NorenUp ↑