DHH Offended By RSpec, Says Test::Unit Is Just Great
As an outspoken and opinionated guy, David Heinemeier Hansson (a.k.a. DHH), creator of Rails, is no stranger to a little bit of controversy. He frequently sets off interesting debates on Twitter from his @dhh account. The latest is, perhaps, the most involved yet and has been rattling on for a couple of hours today.
So what's the beef? RSpec and Cucumber versus.. Test::Unit. It's no secret that DHH is a happy Test::Unit (and fixtures) user. Last October he tweeted:
But here's what kicked off today's debate:
Naturally, this brought a plethora of heckles, support, snark, and questions from DHH's followers, including:
More specifically, though, DHH noted that this gist comparing some Test::Unit tests to RSpec triggered his statements.
But back to the debate. JD Skinner asked: What testing tools do you use/recommend? DHH replied:
Jeremy Welland asked: So why do you think RSpec/shoulda's approach is so popular? DHH's response:
The debate rattled on for a few hours amongst various Ruby developers on Twitter (including Dave Thomas and Bryan TATFT Liles) and if you want to really dig into it, check out DHH's Twitter account and follow through some of the responses.
I agree with DHH for the most part, though I use a mixture of RSpec, Test::Unit, and Minitest just to "keep my hand in." RSpec (and BDD) did seem to become "the way" to do testing in many circles, though, even when it didn't present any significant benefits. Cucumber, following on from RSpec, had a similar experience.
This debate is important, though, not because DHH is right or wrong or because one testing system is better than another, but because it wipes away some of the lines in the sand and assumed "correct way" attitudes that exist. If you want to use Test::Unit, it's not "old and uncool" (yes, I've heard this) and you should get on with it (DHH is using it fer chrissakes.) Likewise, RSpec and Cucumber are not panaceas or catch all solutions but may have significant benefits you can take advantage of.
Research your options and pick the tool that makes sense for you and your team. DHH has and he's sticking with Test::Unit. What's your take on it?
Update: DHH recommends this post about testing which suggests you check out Test::Unit first before considering more extensive frameworks. A good read!
March 30, 2011 at 12:05 am
It sems like cucumber is an extra step on top of testing, only useful for showing an intermediate step between no coders and coders. I have now use for it; non-coders don't need to see my tests. They don't care.
March 30, 2011 at 12:06 am
This is just like "which is better, Ruby or PHP?" or jazz vs. pop. There is no 'correct' answer, just a bunch of people with different tastes and opinions. I'll use the tools that suit me best, and I'll be happy.
March 30, 2011 at 12:07 am
In evaluating test frameworks, I believe that looking at the output for test failures is more important than the syntax for developing tests. I find that when I really need a test framework to be clear and effective is when my tests are unexpectedly failing (or when teaching). A while back I compared test::unit, rspec, and shoulda: http://www.ultrasaurus.com/sarahblog/2009/08/ruby-unit-test-frameworks/
March 30, 2011 at 12:20 am
Hey Peter, didn't you tweet about a year ago how you don't follow @dhh?
March 30, 2011 at 12:29 am
I might have. It's not necessary to follow someone to see their tweets. Also, you still see someone's tweets if someone you follow retweets them (unless you block them - but I like seeing the "best of" DHH that other people retweet). That's what happened in this case.
March 30, 2011 at 12:39 am
I think the modern Test::Unit replacement in Ruby 1.9 is underappreciated.
Minitest has built-in "describe" and "it" blocks for readable test names and easy grouping. And it was built from the ground up for speed and simplicity. It even has simple chained matchers (like RSpec) and a minimal mocking facility.
And a major contributor was none other than the original author of RSpec...Steven Baker!
March 30, 2011 at 12:46 am
Agreed. I've been meaning to do a brief how-to on minitest/spec here.. I better pull my finger out.
March 30, 2011 at 12:57 am
Ok, so DHH says that he doesn't like Rspec, that's just fine.
But saying that he's actually sad about its proliferation, that's too much.
March 30, 2011 at 1:00 am
The idea of "offense" also struck me as a bit odd but he's not one for understatement!
March 30, 2011 at 1:17 am
I like RSpec more for it's specdoc output than anything else. Cucumber keeps me from writing too much code, and from forgetting exactly what I'm trying to solve. I couldn't imagine life without it.
March 30, 2011 at 1:53 am
I just started my first project using RSpec. The impetus behind this was that all the tools that helped me avoid the startup costs of Ruby 1.9 and Rails. Running RSpec with Spork is simple compared to getting it to work correctly with Test/Unit. When I was using TestUnit, all the tools seemed to be aimed at RSpec.
March 30, 2011 at 3:06 am
I'm with Joe, RSpec's output is nice.
And Cucumber...complex? Seriously? I'm often kinda embarrassed when I explain to folks how it works. It's so simple, even a cave man could do it.
I like RSpec and Cucumber, and @dhh's proliferation makes me sad.
March 30, 2011 at 3:08 am
There's a pretty big gap between what a user wants to accomplish and specs; which cucumber fits the bill perfectly. Why does this method return true if the provided email and password match a record in the database? Oh, because the user wants to sign in to view his stuff. Scenarios drive specifications, which drive code. This process works excellent for me, and keeps my eye on what's important.
March 30, 2011 at 3:23 am
And there's nothing new here.
Plenty of us have been saying it for some time. This isn't net. TDD/BDD is about the process and not the tools.
Use what works best for you. But, please, do actively consider what works best for you.
March 30, 2011 at 6:52 am
Is there an alternative to cucumber using test::unit and following the same principals of simplicity? I personally have a bit of a gripe with stories and wish there were more people on the side of making acceptance tests not rely on stories and just let you get to the basics with ruby code. I'm assuming you can just use capybara without writing the cyclist stories and marchers but I really haven't seen much support for this or using this sort of acceptance testing style with test::unit. In my case and in DHH's case, I'm the client so I can do without non coder written specs. I also feel that if you need to generate some sort of story output, one could be extracted from your low level ruby based acceptance tests. Ruby is more flexible than reg ex.
Disclaimer: written from my phone so please excuse minor spelling errors :)
March 30, 2011 at 7:22 am
Dave is right about Cucumber. Think about all the times your cukes have failed because you wrote "And I visit the seller's overview page" instead of "And I am on the seller's page".
The units of YOUR memory required to keep a cucumber step definition recalled is much higher than a webrat step for ("visit overview_seller_path" in this case), and requires much less work to implement (less typing, no need to map "seller's overview page" in paths.rb).
Cucumber adds a whole layer of complexity to your integration tests and have no place in projects which aren't client facing.
March 30, 2011 at 8:37 am
I agree with DHH here, and that's rare ;-)
By the way, for all those who don't like the output of MiniTest or test/unit, check out Turn.
It's as simple as require "turn" in your test helper, and then you've got pretty and descriptive test output.
March 30, 2011 at 8:46 am
I occasionally use Shoulda, but only for a tiny bit of context/should syntactic sugar, never macros or anything else. The rspec/cucumber worship has never made sense to me, but I'm not now and never have been a contractor. I've found that the best predictor (not 100%, but strong correlation) is that contractors seem to care deeply about rspec/cucumber, where FTEs find them fragile and unnecessary.
Personally, I especially loathe rspec's assertion syntax. shudder
March 30, 2011 at 9:29 am
Thanks for recommending our article on testing (I'm the founder of Object Reload). We're happy to see people finding our tips useful.
Geoffrey: We actually profiled test/unit vs. minitest in one of our applications and minitest's claim that it was build for speed simply didn't hold up. They both performed similarly, with test/unit often coming on top. Obviously, your mileage may vary.
Joel: Cucumber is great as long as you have your clients read/write tests. Otherwise it's just an extra layer of abstraction. Programmers think better in code.
Evan: Definitely. That's why we didn't bash rSpec altogether. But we believe it's better to start with something simple like test/unit and grow into a more complex framework than vice versa.
March 30, 2011 at 10:27 am
Wonder what the guys at Hashrocket think. As far as I know they're totally for RSpec (just like me), saying it's the "Rails Way". As Evan, I think use what fits you best and don't get people angry who put their free time and effort into something others like and use (Github facts for RSpec: over 1600 viewers and more than 150 forks)!
Hope that the Ruby community isn't on a suicidal trip, destroying good people and good projects. You don't like it - keep it for yourself. That's what I do and nobody seems to be offended or hindered while doing their work.
This discussion almost reminds me of python: "there is only one way of doing something", which I don't really find true and appriciated Rubys (community) for being WHAT-FITS-YOU-BEST-WAY and HAVE-FUN-AND-RESPECT-FOR-OTHERS.
Z** S***'s case is coming into my mind. Hope that David C. and the Rspec team don't leave the Ruby community etc. :(
March 30, 2011 at 11:46 am
Ruby, Rubyists and Rubyism again and again. You guys write so much crap about your tastes and likes. Who cares? Well, only the people that prefers tastes over facts. TDD and BDD are just buzzword, both Test::Unit and RSpec fall into the category of unit testing. Why can't you keep your preferences for yourself, and write articles based on facts, numbers, and analysis? That's what good programmers do, on the other hand, bored and useless devs write articles about their tastes.
March 30, 2011 at 1:08 pm
I agree with DHH. Test/Unit do its job perfectly fine. Many developers prefer to test with RSPEC? Great but rspec shouldn't be considered the "standard" or "the right way" to test.
March 30, 2011 at 2:10 pm
This is really a personal taste matter. I prefer reading Rspec specifications over Test::Unit tests. And tests are all about readability, right?
What I really never liked nor find it useful is Cucumber. Too much extra work and no real benefit. I'll never convince any real client to read my Cucumber specifications... Good theorical idea, but useless in my opinion.
March 30, 2011 at 2:16 pm
I agree with skrat. Inflammatory claims w/ no evidence or examples don't do to much for me. I think it's good that this question was raised but someone with that much influence / experience / knowledge should explain where he's coming from.
March 30, 2011 at 3:16 pm
Check out Contest. It takes Test::Unit and makes it perfect with 100 lines of code. I use it on everything.
Explanation: http://blog.citrusbyte.com/2009/05/19/introducing-contest/
Github: https://github.com/citrusbyte/contest
Ruby 1.9 has similar niceties baked into Test::Unit, which may be worth looking into. Contest works on 1.8 and 1.9 so I'll probably stick with it for awhile.
I agree with DHH, I don't like how RSpec dumps crap into all the objects, and I abandoned it a while ago after finding out it was causing too many bugs with this approach. Testing should be simple, and should never create bugs from its implementation ever! Also, the documentation was fairly abysmal at the time.
March 30, 2011 at 3:44 pm
I prefer the output of RSpec - that's a factor for me. There is a balance to be had here. For a while it seemed as though everyone had a testing framework, and the barrier for people learning TDD became larger simply on the amount of choices and opinions (and lack of examples). As a preference, I enjoy working with Factory Girl and RSpec.
As far as the Cucumber situation, I think I understand his point a little more. Unless I am working with a team where people are committed to using it - not just talking about how cool it is, but actually using it - then I don't see as much of the value, as the Unit/Integration tests cover the majority of what needs to be tested. I don't think it's complex, I just don't see it necessary in all situations.
@Joe Fiorini
Curious if you could elaborate how Cucumber helps you write only the code you need, versus the other tests that you write (Unit, Integration, etc)? Don't good unit tests help you write only the code you need? I'd ask you in person, but alas .. ;)
March 30, 2011 at 3:55 pm
I use Cucumber. I never show features to users.
So why do I use it? Because I do TDD. Writing a Cucumber feature is writing prose, not code. I have to clearly and succinctly lay out what I want the system to do, without concerning myself with how it should do it. That's reason #1.
Reason #2: After I've finished writing and implementing a feature, I have an integration test. To me, that's almost a side benefit. I prefer to think of it as having executable documentation.
Reason #3: Anyone who joins the project reads the features - then they understand the project.
I never show the features to end-users.
March 30, 2011 at 3:57 pm
Remember kids, using XYZ framework just because ABC said so is also (and is the worst kind of) cargo-culting.
"My hero said I should use this product in this manner and so I do."
If you don't understand *why* you are using a certain approach, everything else is superfluous.
March 30, 2011 at 6:08 pm
I value Cucumber for the separation of "what" should be true, from "how to test if it is true". When changing aspects of a site that are user visible, or even just large enough technically (Rails2 -> Rails3) this separation is very valuable. I can run the same features on different step definitions to verify they pass on ole and new sites alike. While I like the .should notation from RSpec, I like that test unit can include a message indicating what the failure was in human terms.
The bottom line is ensure the software does what it is supposed to do, and provide a tool for programmers to verify this before it goes live, and to understand what it is supposed to do before deciding how to change it. Any good test tool and test suite can achieve this. It all comes down to style, and minor strengths and weaknesses.
March 30, 2011 at 6:40 pm
Examples of this added complexity would be much appreciated by the people who aren't knee deep in the development of these libraries
March 30, 2011 at 7:16 pm
The only thing that really sets RSpec above Test::Unit, in my opinion, is the clarity of expected versus actual values.
It's immediately obvious which of x and y is expected, and which is actual, in RSpec:
x.should == yHowever, for Test::Unit, it's not so clear:
assert_equal y, xI've used both for years on different projects with many developers, and I constantly find "backwards" assertions in Test::Unit -- but never so with RSpec.
March 30, 2011 at 10:01 pm
I agree with Ian, Rspec just looks better, its more legible and that makes me want to use it over test::unit, its also why i started using ruby over php, at least in the beginning. @Grosenbach i love your work keep making those screencasts!
March 31, 2011 at 2:51 am
dhh claiming a "cargo cult" acceptance around RSpec & Cucumber is like the pot calling the kettle black. The same can, and certainly, is said of Rails.
I tend to use RSpec because I prefer the syntax of 'object.should' instead of 'assert_equals' and friends. It's not that RSpec has anything over Test::Unit per se, I just like the syntax better. I have more than 11 years of TDD experience with JUnit, SUnit, Test::Unit, and RSpec -- so I'm no beginner at this game. I just know what I prefer.
Also, a lot of people are talking about the complexity of reading and maintaining RSpecs due to nested contexts and such. If you have a 500+ line RSpec file with 5+ nested contexts (as has been posited more than once in this debate) you may be doing something wrong. You might need to go back to the drawing board and learn how to break things out more.
March 31, 2011 at 6:16 am
It seems to me that a vital point is being lost. It is the 'Driven' in TDD or BDD. To a guy like DHH, most likley writing the tests first is habit, however for most of us mere mortal, the 'Driven' part means writing the tests first, and test::unit sortof leaves that pretense behind, whereas RSpec thrusts it to teh forefront (the B versus the T and the Spec v. the Test).
Writing the test after the code (as Test::Unit facilitates fine, and sadly RSpec also facilitates) is the issue that needs to fostered.
So if you are using RSpec and writing tests first, I suggest you ignore this controversy. And if you are using Test::Unit and writing tests afterwards, or worse not writing tests at all, and you smugly agree with DHH, then I fear you miss the point.
Nate
March 31, 2011 at 8:06 am
In the German Ruby community we had a long time ago a discussion about test/unit versus RSpec. One important argument against RSpec to me was the fact that RSpec pollute the global namespace with methods (extending the Object class and the Kernel module). So it changes the behaviour of your testet objects! This is in practice not a real problem but in an architectural point of view it is simple a failure. The test/unit, minitest and so on frameworks live complete in the Test module and separate in this way the test code from the tested code (unless you write tests for one of those frameworks ;-).
March 31, 2011 at 2:22 pm
I like the simplicity of Test::Unit and the fact my test code feels as close to the code I am testing as possible, without any unnecessary abstractions. I like just asserting that 1 ought to equal 1, or that the number of things ought to have changed, in simple Ruby syntax. So I'm with DHH on this one.
I like that you posted this up, because I'd felt for a while that by not using the newer test libraries I was behind the curve. Nice to see that's not necessarily the case.
March 31, 2011 at 3:25 pm
@janfri: One thing I've learned over the years is that if something's not a real problem in practice, it's not a problem - period. :)
March 31, 2011 at 4:06 pm
Ok, we don't definitely need a flame war about something as important as testing your code. IMHO it really depends on the developer and the team, I wouldn't be the first to say that should use what you're more comfortable working with, and hopefully what makes you even more productive. That said, I'm an almost exclusive Cucumber/Rspec user, I do minitest/test-unit only for foreign projects from time to time, and I have to say, it's the methodology that matters here.
I don't see any points if you're using Cucumber and Rspec to translate TDD into these tools and be cool about it. It has been done, it has been successful, but it's also the cause many devs simply "don't seem to get it". These tools excel in BDD, executable specifications, Acceptance-Driven Planning and Development, and many other topics people should really get into so they can value their tools. It also depends on your domain in some fashion, you won't certainly have any value by telling your customer that "when I use the << method I add a message to an asynchronious message queue for latter processing", for me it doesn't add value to clients, although it might even add value for developers. Mini-BDD such as shoulda and minitest/spec are great tools. And I really mean great tools, being a rspec user I sometimes found myself putting shoulda code (all right, matchers and the like, but still), but that's not full-blown BDD, the authors acknowledge that. So, test/unit? Simple? It's relative. Simple for JUnit, NUnit, yes. Simple for assert_equals yes, simple for custom assertions, yes. Powerful? Ummm. Readable? Ummm. Process-Oriented? Ummm. Where Ummm actually means that are better solutions based on that criteria, and IMHO Rspec/Cucumber are one of those. I wouldn't ever, ever again, write a Rails integration test with that API, when I can visit, click_link, etc. I wouldn't ever again assert something.some_col.size instead of something.should have(n).items.
But again this is me. And I point is, use the right tool for the job, *your* right tool for the job.
March 31, 2011 at 5:11 pm
Some people are overreacting. DHH just said his opinion that RSpec/Cucumber aren't aesthetically pleasing and that recommending them over T::U for newbies is a bad idea.
March 31, 2011 at 5:34 pm
Wait a minute. Is this supposed to mean I shouldn't use RSpec/Cucumber because the vaunted DHH said it makes him sad? There's a lot of things in the world that make people sad. Get used to it. Is this supposed to mean I shouldn't use Test::Unit because the vaunted David Chelimsky 'says' it makes him sad? He too would have to have to get used to it. There's a lot of things that make people sad. I respect both their work, I've used both their work. Am I going to stop using one or the other because one of them gets a gut wrenching feeling about the other? NOT!
Use what works for you, regardless of who sees the tests. If one is more natural to your way of thinking and really helps you knock out code because you understand intuitively what needs to be done from the way the tests 'read' or how high above or close you get to the actual code, then by all means use it. Neither testing apparatus is better than the other. Either one will accomplish the goals you have set before you by the software requirements of the client. THAT, in the final analysis, is all that matters. Which ever one best helps you to deliver the best code you can for the requirements is the one you should use, regardless of the position in the community of the writer/user/supporter of said testing kit.
Anything less than that is just plain wrong and a disservice to you and your customers. If what the major/minor deities has to say that significantly impacts your decision making capabilities, there's something wrong with your thought processes. And, at the risk of offending the great DHH, come with the evidence backing up your claims or sit back and let your inner demon scream itself hoarse because it can't get to the keyboard. Comments like that are sure to start flamewars and, somehow, I think you know that.
March 31, 2011 at 7:14 pm
@Mark Wilden:
Prose... I've always just used pseudo-code at the intial design phase for that. To me if you're making the pseudo-code so technical that you're even parsing it and keeping it around, its function is broken and now it's actually become part of the implementation.
April 1, 2011 at 2:11 am
What's funny to me is that some might take umbrage at "one true wayism" from the guy who invented Rails. I mean, there are books called 'The Rails Way'. Seems that boat's already sailed, folks.
April 1, 2011 at 3:13 am
@Brian: And yet, "The Rails Way" is anything but (it's really the HashRocket Way). Unusual view style (using decent exposure), HAML (not ERb), RSpec (not Test::Unit).. it's about as far from the DHH style as it gets ;-)
April 1, 2011 at 3:44 am
Hah, the complexity of Rails upsets me. That's why I ditched it long ago.
April 1, 2011 at 9:35 am
I have always used Test::Unit and Mocha and have always been happy with them.
I could never wrap my brain around the need for alternatives like RSpec, even less so for Cucumber. Seeing this many people praising them and using them in their open-source projects, I have given them a chance but I never got it.
If anything, trying them out showed me just how great a fit Test::Unit is for my testing needs.
I have seen so many bad quality, even useless tests using RSpec for the sake of it, in quite a lot of open-source Ruby projects... it's a good thing DHH is reviving this debate.
April 1, 2011 at 12:08 pm
Well, I agree that it's a matter of taste and approach. I can see the value for some projects in BDD or TDD. However, for my projects, I feel that the code and it's documentation are much more precise than English can ever be in describing features. So I am content to thoroughly unit test the code after I've written it.
And I like to unit test in the simplest way possible. So I use my own version of nanotest combined with watchr. It's the ultimate in light-weight unit testing, and I really like it. Just assert { whatever } and the test is good to go.
As for everyone else: try out different tools, and then use the ones which are most convenient for you or your team. Ruby is all about programmer convenience, so choose a unit test/bdd/tdd framework that is you and other people involved in the project like best. Keep in mind the Ruby ideals of TIMTOWTDI, MINASWAN, POLS, etc. :)
April 1, 2011 at 10:12 pm
Why use Test::Unit, RSpec or Cucumber when you can use AffirmIt? Today on Twitter, DHH mentioned that he was going to switch Rails 3.1 tests over to AffirmIt.
April 2, 2011 at 2:56 am
I prefer rspec because it looks more readable and I like the output. However, I only like it slightly better than test/unit and feel that it was overhyped. I'll continue to use it because I've spent so much time learning it, but I will never spend any of my time trying to convince others to switch to it.
I'll continue to use both rspec and test/unit because I want to be familiar with both. Usually, one has little choice about what to use because you have to use what everyone else at your company is using. Being familiar with both for job interviews is the most important issue for me rather than being a guru in one.
I liked cucumber at first, until I realized what I liked about cucumber was really webrat/capybara. Capybara is really powerful for writing integration tests, so I'm more of a capybara fan than a cucumber fan.
April 3, 2011 at 11:38 pm
It seems like there are two debates here. One is a question of which library to use and another is what idioms to adopt.
I've long been a fan of using rspec with straight-forward tests (using the basic features). I like nesting contexts so the edge cases can be tested and visualized.
Yes, lots of nesting is bad, but the pain one feels when this happens serves and good motivation to make the software simpler by refactoring.
Looking at DHH's gist, https://gist.github.com/893027, it seems like he is against the idiom that has been pushed by some (arguably the majority) in the rspec community. I agree with DHH there. Breaking things up that small makes things more complicated in many cases and makes the test suite slower.
So yes, keep things simple and do whatever works for you. Avoid religious zealotry and be pragmatic. If there's anything that I've learned when it comes to testing, it's that over-reliance on one technique (and worldview) causes unnecessary complexity and unmaintainable software.
April 5, 2011 at 5:24 pm
This anti-cargo-culting is just cargo-culting in reverse kids.
Cargo culting has it's positives. It is better for a JR rails developer or even a mid to follow the cult of the most efficient coders leading the project. This is right up there with 'dont use generators' another wad of crap.
CONVENTION over *
A developer may cargo cult, and to you that may seem bad, but rails code that looks like rails code is so much more productive and easier to work on as a team then rails code that looks like ruby code.
Cargo cult until you have your own master rails programmer title. Then do all the thinking for yourself. If you think before you have style and intuition with rails you will just be hurting yourself and others.
So yes, cargo culting is good. But whatever, I like RSpec over Test::Unit any day so what do I know ;)
April 11, 2011 at 2:54 am
I always had the guts that Test::Unit was the simplest and straight forward.
I never liked the added complexity of rspec.
Rspec might help big teams of developers to make test easy to read.
But overal I agree with DHH.
btw, ruby 1.9 Test::Unit is so damn fast.
April 11, 2011 at 10:07 pm
Ewwwww fixtures!
April 12, 2011 at 2:34 pm
Some discussions in here make me remember about an interview for a J2EE job I had back in 2007.
When one (supposed to be) architect asked me about "Why I like Rails better than any of the J2EE framework, such as Struts, JFC, GWT?", one of my reason was "In Ruby you don't have to do compilcated XML mappings for the application to recognize the controllers IF YOU DON'T WANT TO"
The interviewer perplexed: "What? Do you think that XML is complicated?"
I've even worked with XML from the time that guy was not born yet. However the dumb ass failed to recognize that "Doing nothing is better than doing something, because doing something can potentially cause errors". In Rails, you map the URLs only when you want to, and in Java, you have to do it all the time.
Anyway, back to RSpec and Cucumber, my opinion is "Having to learn nothing is better than having to learn something". And the syntax, keywords and everything else of RSpec are ugly to a professional developers. Only stupid users need specs in English, and they don't read code anyway.
April 13, 2011 at 2:57 pm
Test::Unit encourages unreadable implementation-dependent tests. The "should" syntax of RSpec, at least in my experience, encourages more thinking about behavior. That's why I started using RSpec way back in 2007, and I recently found myself maintaining other's Test::Unit tests that confirmed these impressions.
I'm sure it's *possible* to write readable Test::Unit tests -- perhaps DHH already does so. But RSpec actually follows the Rails philosophy of making the right thing the *easy* thing. I don't know why anyone would voluntarily use Test::Unit today.
I've said for a long time that DHH was, at this point, a liability and a threat to the Rails community -- he developed something wonderful but has had a hard time letting it evolve in the hands of others, I think. These tweets tend to make me think I was correct in that assessment.
Pingback: 005 RC Testing Tools for Rails — Rails Coach
April 17, 2011 at 2:38 am
I agree with DHH. The RSpec lacks simplicity. It is the J2EE of the testing frameworks. It would benefit if the RSpec committers had learned something from Rails.
What if there was a test framework that lowers the barrier to entry for less experienced / skilled developers? Something that just works out of the box instead of having to do some cute gymnastics like "World(CrapGoesHere)" inside the configuration file?
Pingback: Rails 3.1 include CoffeeScript, jQuery, Sass as default | Rails Ant
April 18, 2011 at 3:50 pm
What a pointless debate. While you all fret over which hammer is most efficient or aesthetically pleasing to you, I'll be driving in nails with whatever works best for me and my team.
Approach wars = fanboi/troll fodder. How 'bouts we all just get back to coding cool products and services that work?
April 18, 2011 at 6:17 pm
Bala: Funny, I'd say you got it backwards. I use RSpec because it's *easier* to use than Test::Unit. Test::Unit assertions look like Java to me; RSpec looks like...well...like Ruby. It would benefit DHH if he learned something from RSpec, IMHO.
What do you find hard about RSpec?
Pingback: TDD z użyciem Test::Unit
May 29, 2011 at 12:19 am
Test:Unit is clunky, especially with the terrible fixtures. Fixtures are just terrible things to write. Why not just use a seed.rb test file? Don't get me started on the uselessness(and pointlessness) of functional and integration testing built into Rails. Unit tests do work but are hardly optimal.
RSpec can get complex but its ability to document expected behavior in a Ruby app is unparalleled as its ability to complete a test without stopping on an error.
I think this little tantrum from DHH really shows he wants to be a cult leader where all Rails programmers blindly follow him.
I have used Rails since 1.2 and have always enjoyed it and been productive but face facts. Rails would be in decline if not for the Merb guys. Merging Rails and Merb has been the best thing for Rails and DHH deserves no credit for Rails 3, except for allowing the merge to happen. Yet he still acts as if it is his work alone that made it so good-if anything he is a detriment to Rails and would love to see him step down.
Then maybe REST can be properly placed as an option and not the default.