Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/
Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Thursday February 07, 2008
04:54 AM

Realistic, Down to Earth, and Swarming with Magic Robots

[ #35600 ]

Ruby's a fine language in many ways. It's not Ruby's fault that you can occasionally write a line of code that reads almost like a very short, very very simple English sentence. It's not even Ruby's fault that some (probably well-meaning) people look at that example and try to push that further than it should go (likely just beyond "See Spot run.").

When _why invents something, it's new. It's often bizarre, but always whimsical and charming.

You can tell _why didn't invent rspec (an introduction to RSpec - Part I).

Besides the more-or-less-pointless renaming of "test" to "behavior" (No kidding, you're testing the behavior of your code? What have my tests been testing for the past decade, sparkly pink unicorn content?), I thought the point of inventing a dee-ess-ell was to be able to choose the most appropriate linguistic representation (syntax most appropriate for the semantics) with concepts lifted directly from the language of the problem domain.

(From that sentence alone, you can tell I don't get invited to the best post-Rails Ruby parties.)

As happens occasionally, the RSpec community circa 2005 or 2006 discovered what the developers of Perl knew in approximately 1988 (for those wondering if I made a snarky typo by accident or on purpose, 1988 was twenty years ago). To wit, it's nice to associate names with test assertions.

The proper cultured Rubyist response is probably "our syntax is better because it doesn't look like we're calling functions."

That's true, but it only applies to the output, which is the least important part of the process -- and, frankly, if the whole point of waving your Big Sword Of Super Duper DEE-ESS-ELL +2 Against Enterprisey is to improve the reading and writing of code, then you could produce this output from any language such as, for example, COBOL, Malbolge, or Java.

I have nothing against fluent interfaces, and I'm perfectly happy to write my test code as actual code. That's fine. Yet how ironic that the actual code (you know, written by people who believe that dee-ess-ells are basically English) reads like the code equivalent of pidgin English. (Props to big daddy P.C.) NOUN IT "description of task" DO some Ruby code END.

It do, do it? Can it has cheezburger, too?

This here is the problem with so-called internal dee-ess-ells: your lack of abstraction leaks big. A real domain-specific language could fix this with a trivial grammar change.

Even with this silliness, the output of RSpec is substantially better than that of Ruby's standard testing module, which is at best functional in that it tells you how long the test suite took to run, oh, and if a test failed. I continually miss Perl's Test::Class and Test::Harness, at least for those tests which I absolutely must write in the host language. (See also Jonathan Rockway's comparison of RSpec to Perl's Test::More.)

The question you're probably asking yourself right now isn't "What then does BDD want to be when it grows up?" (Another good question is "Exactly how serious are you about leaky internal pidgins?" To that I answer "Reader IT should be able to pick out truth from over the top satire DO reader.ponder END TRANSMISSION FULLSTOP." Bonus points for figuring out where this entry's title comes from and why. Zing!)

I'm a generous guy at this hour, so the answer to the non-obvious question is "FIT, ironically enough, is a framework for describing the desired behavior of software in the actual language of the problem domain."


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Realistic, Down to Earth, and Swarming with Magic Robots 17 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • sparkly pink unicorn content

    Yes please! My niece would love that. Both sparkly and pink, two things she is (almost) obsessed by.

    Oh, what, you mean to say that the nasty folks are removing testing for that, and instead are replacing it with testing code behaviour? Boring. If they do that, I don't think that Ruby is going to be her language of choice.

  • I've never quite understood the RSpec crowd's obsession with renaming things, but as a library RSpec kicks the default ruby Test::Unit's arse so comprehensively otherwise.

    Nor do I understand the style that has them use do ... end style blocks to wrap code that, at it's best looks declarative. It's not impossible to write:


    describe SomeClass {
        it "should be instantiable" {
            SomeClass.new.should_not be_nil
        }
    }

    which seems a good deal cleaner. Many ruby progr
    • I really, really, really hate that extraneous fscking do. If only the language would let me declare things so I could write:


      describe Something
          it "should do stuff"
              do_stuff_with_it
          end
      end

      I'd be a good deal happier. Yes, I could write a source filter type thing in the runner, but I don't want the pain of having to parse the whole of the rest of bloody ruby just to get rid of that stupid do

      But, hey, ruby pays my mortgage and I'll swap the aesthetic pain
      • So that means you'll be back to Perl 5 if 5.12 has named parameters to subs and/or methods? ;)
        • Probably not. See the comment about the mortgage.

          I'm holding out for malleable syntax, real objects, proper garbage collection and decent function/method prototypes.

          And a fanatical devotion to the Pope.

          It's more likely to be things like DateTime that lure me back - Ruby's date handling is woeful.
          • Care to be more specific about Ruby's date handling issues?
            • Go and read the documentation for the DateTime suite of modules. Now point me to anything as comprehensive and well thought out on rubyforge. At least Ruby on Rails is starting to address some of the problems in its earlier implementations of things like 1.month.from_now by inventing/rediscovering the Duration class.

              http://www.perl.com/pub/a/2003/03/13/datetime.html [perl.com] is a good read too, in which Dave Rolsky explains the issues with the ad hoc nature of most Perl calendrical modules before the DateTime better

      • Have you seen Devel::Declare? It’ll provide half a macro system – for Perl 5.

    • Many ruby programmers appear to be blind to ugliness of do declaration end though.

      Goes with the territory. Lisp programmers don’t even see the parentheses any more, nor do XML people consciously notice all the angle brackets. I used to be blind to the iffiness of Perl’s deref syntax.

    • I quite agree about Ruby's Test::Unit being barely functional. I very nearly ported Test::Builder and Test::Class to Ruby a year and a half ago, when I was doing more Ruby hacking. Then I realized that instead of spending the next several months reinventing all of the tools I like and use, I could spend the next several months building useful things that don't already exist, and stopped writing Ruby code.

    • I've never quite understood the RSpec crowd's obsession with renaming things...

      This is what grates me. It's clear that RSpec is a tremendous boon to Ruby testing. I'm all for that! I just wish that this goodness weren't couched in such tiresome wankery over decades-old concepts repackaged bizarrely.

      There's no shame in borrowing good ideas! Just please stop renaming them, explaining them badly, slapping bright yellow racing fins on them, and pretending that they're completely new and different. Th

      • This is where we differ, I think. I don't really give a bugger if people want to give things fancy new names, so long as the thing itself is useful. The RSpec crew have taken the view that the reason many people don't do Test Driven Design is because it seems arse about face to them. Testing is what you do after you've done the programming after all. (I remember once having a rather voluble argument with someone about the benefits of running your test before implementing anything to make sure that it failed

        • I don't really give a bugger if people want to give things fancy new names, so long as the thing itself is useful.

          I care, if it confuses the innocent. Count the number of people who say "We use BDD and TDD" or "I'm learning BDD and TDD". The number is non-trivial.

          Also, ISTR we all called the practice "Test First Development" until around the time Beck published "Test Driven Development", which is definitely a way better name for the process.

          Agreed. Also, I prefer the term Test-Driven Design, but

    • Many ruby programmers appear to be blind to ugliness of do declaration end though.
      That's why I use brackets instead. ;)

  • Behaviour Driven Development is an Agile development process that comprises aspects of Acceptance Test Driven Planning, Domain Driven Design and Test Driven Development.
    Um... wow. I'm sure the magic shining robots... er, Magic Shining Robots have some role to play here. Seriously, when the first sentence contains that much Capitalized Meaningless Drivel, it's safe to move on without reading more.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.