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."
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.
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
}
}
do declaration end though.Or to put it another way
pdcawley on 2008-02-07T11:51:47
I really, really, really hate that extraneous fsckingdo. 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 stupiddo
But, hey, ruby pays my mortgage and I'll swap the aesthetic pain of the extraneous do - which I can cover by using curly brace blocks anyway - for not having to unroll@_every time I extract a method.
Roll on Perl 6 (and sorry for not contributing, I seem to have ended up maintaining a Ruby based blogging engine which rather eats into discretionary hacking time - that'll teach me to scratch and itch and then submit a patch).Re:Or to put it another way
tsee on 2008-02-07T14:20:07
So that means you'll be back to Perl 5 if 5.12 has named parameters to subs and/or methods?;) Re:Or to put it another way
pdcawley on 2008-02-07T18:51:00
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.Re:Or to put it another way
djberg96 on 2008-02-07T19:58:50
Care to be more specific about Ruby's date handling issues?Re:Or to put it another way
pdcawley on 2008-02-08T06:19:44
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 like1.month.from_nowby inventing/rediscovering the Duration class.
http://www.perl.com/pub/a/2003/03/13/datetime.html 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 mousetrap got built.Re:Or to put it another way
Aristotle on 2008-02-07T16:34:26
Have you seen Devel::Declare? It’ll provide half a macro system – for Perl 5.
Re:Calm down dear, it's only programming
Aristotle on 2008-02-07T16:21:43
Many ruby programmers appear to be blind to ugliness of
do declaration endthough.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.
Re:Calm down dear, it's only programming
Dom2 on 2008-02-08T09:27:36
I findtr -d '()'makes most lisp a lot more readable.:-).Re:Calm down dear, it's only programming
Aristotle on 2008-02-08T09:48:45
Let me guess: for Perl that would be
tr -cd '[:alnum:]'?Re:Calm down dear, it's only programming
chromatic on 2008-02-07T18:32:50
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.
Re:Calm down dear, it's only programming
chromatic on 2008-02-07T20:35:27
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. That's distracting noise.
Re:Calm down dear, it's only programming
pdcawley on 2008-02-08T06:32:16
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).
They think that, by recasting tests as executable specifications and (in the more recent iterations) stories, they'll convince more people to start writing tests first, which can only be a good thing.
The trouble is, they risk (succeed in) pissing off those folks who are already convinced of the value of writing their tests first by renaming a perfectly good set of names. Arguably, one of the benefits of calling it Test Driven Development is the very same crogglement that the BDD types are trying to reduce.
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. Chelimsky and friends are just attempting to find a better name again and, from our point of view at least, they've failed.Re:Calm down dear, it's only programming
chromatic on 2008-02-08T07:39:13
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 that gets to the point you made in your first paragraph that "something" is what you do before/after "something" else. My best strategy for that is encouraging those companies to send out lots of press releases about their development approach and hope that the resulting noisy failures will convince the rest of the world not to do things that way. So far so good.
Re:Calm down dear, it's only programming
djberg96 on 2008-02-07T21:09:53
Many ruby programmers appear to be blind to ugliness of do declaration end though.That's why I use brackets instead.;)
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.Behaviour Driven Development is an Agile development process that comprises aspects of Acceptance Test Driven Planning, Domain Driven Design and Test Driven Development.