I''ve been working on a Rails project with one other developer; he was using Test::Unit, and I was using RSpec. That works OK for a while, but obviously it starts causing pain when you have to check in two places to see if a piece of code is properly tested/spec''d, you can''t use TextMate shortcuts to switch back and forth between code and test, you have to duplicate shared behaviors/test helpers, etc. So when we brought in a consulting team to add some manpower, we realized we had to switch to a single framework. This is a team that''s fairly experienced with Rails and active in the Rails community, but was quite opposed to choosing RSpec. Here are the arguments I heard against unifying on RSpec: * Test::Unit is ubiquitous. Everyone knows it. This is hard to counter; it comes with Rails and is the default. Same reason many people use Prototype even though JQuery/dojo might suit them better. * For that reason, it''s a lot easier to find examples of "how to do something" in Test::Unit than in RSpec. That''s true; several times I''ve had a bit of code that didn''t fall nicely into the MVC hierarchy, and I wasn''t sure how to build up the right context to test it in. If I were using Test::Unit, I could just copy the equivalent tests from Rails core, but using RSpec I had to roll my own. * RSpec is BDD (hand-waving new different troublesome); we do TDD. We''ve covered that ground on this list many times; BDD is an extension and interpretation of TDD, not some newfangled crackpot theory. But people don''t know that. * The team had in fact investigated RSpec a few months ago, and decided they didn''t like it. Some of what they didn''t like has been fixed in 1.0, but of course people aren''t going to come running to re-examine each release, so the bitter taste remained: * #context was defined on Kernel. Not sure if that''s still true for #describe. * Not compatible with tools that expect Test::Unit output. This would(could) be fixed with the runner integration that''s been discussed. * Wasn''t compatible with mocha/FlexMock. Fixed now. But again, it came back to ubiquity, which is a pretty hard problem to overcome. Seems to me that the best way to get RSpec adopted is to find some more visible, prolific plugin programmers and evangelize them to start using RSpec, so it''s not some "neat fringe thing", but a solid, respectable alternative to Test::Unit. Jay Levitt
By all means, they should not ever try anything new. The people of Earth should not have ever adopted the use of the electric light bulb or the radio or the automobile or the airplane or the microwave or the telephone or ... the Internet. No, don''t adopt anything new, just stick to the old ways of doing things. It''s impossible for anyone to improve on anything, right? Bah! Humbug! Obviously, I wouldn''t win that argument either, but that''s because I''m dumbfounded by those who fear change. Change happens whether you fear it or not, so why stress everyone out? BDD is a better, clearer expression of making sure the code meets the client''s needs, why choose an old, clunky interface? They choose the expressiveness of Ruby but fear the expressiveness of RSpec? That doesn''t make sense to me. I suppose they insist on using MySQL and erb templates too, right? Sheesh! (Fans of MySQL and erb, fret not - I''m just trying to make the point that breaking from tradition is not to be feared or laughed at - it''s OK, really, lean back and let RSpec catch you. :) Ubiquitous is not a permanent tag. Rotary phones used to be ubiquitous. Internet Exploder used to be ubiquitous. Horse-and-buggy transportation used to be ubiquitous. Rails is now a large framework with a huge following. They can''t switch everything around overnight every time something better comes along. Luckily it is flexible enough to allow us to use ''something better'' when it does come along. New templates, new test frameworks, new javascript frameworks, new ideas on caching and concurrency, new ORM layers - just because Rails defaults to one thing doesn''t mean that''s the only way to do something and certainly doesn''t mean that''s the best way to do something. Sorry for rambling on. I make a crappy argument here, but it''s hard to express that ''slaps my forehead and says "are you kidding me?!?"'' feeling. I hope I won''t be flamed for being pro- new stuff and pro-rspec in the rspec-users list. :) On 9/16/07, Jay Levitt <lists-rspec at shopwatch.org> wrote:> I''ve been working on a Rails project with one other developer; he was > using Test::Unit, and I was using RSpec. That works OK for a while, but > obviously it starts causing pain when you have to check in two places to > see if a piece of code is properly tested/spec''d, you can''t use TextMate > shortcuts to switch back and forth between code and test, you have to > duplicate shared behaviors/test helpers, etc. > > So when we brought in a consulting team to add some manpower, we > realized we had to switch to a single framework. This is a team that''s > fairly experienced with Rails and active in the Rails community, but was > quite opposed to choosing RSpec. > > Here are the arguments I heard against unifying on RSpec: > > * Test::Unit is ubiquitous. Everyone knows it. This is hard to > counter; it comes with Rails and is the default. Same reason many > people use Prototype even though JQuery/dojo might suit them better. > > * For that reason, it''s a lot easier to find examples of "how to do > something" in Test::Unit than in RSpec. That''s true; several times I''ve > had a bit of code that didn''t fall nicely into the MVC hierarchy, and I > wasn''t sure how to build up the right context to test it in. If I were > using Test::Unit, I could just copy the equivalent tests from Rails > core, but using RSpec I had to roll my own. > > * RSpec is BDD (hand-waving new different troublesome); we do TDD. > We''ve covered that ground on this list many times; BDD is an extension > and interpretation of TDD, not some newfangled crackpot theory. But > people don''t know that. > > * The team had in fact investigated RSpec a few months ago, and decided > they didn''t like it. Some of what they didn''t like has been fixed in > 1.0, but of course people aren''t going to come running to re-examine > each release, so the bitter taste remained: > > * #context was defined on Kernel. Not sure if that''s still true for > #describe. > > * Not compatible with tools that expect Test::Unit output. This > would(could) be fixed with the runner integration that''s been discussed. > > * Wasn''t compatible with mocha/FlexMock. Fixed now. > > But again, it came back to ubiquity, which is a pretty hard problem to > overcome. > > Seems to me that the best way to get RSpec adopted is to find some more > visible, prolific plugin programmers and evangelize them to start using > RSpec, so it''s not some "neat fringe thing", but a solid, respectable > alternative to Test::Unit. > > Jay Levitt > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- Cheers, Kevin Williams http://kevwil.com/ http://www.almostserio.us/ http://kevwil.jaiku.com/
El 16/9/2007, a las 15:38, Jay Levitt escribi?:> * Test::Unit is ubiquitous. Everyone knows it. This is hard to > counter; it comes with Rails and is the default.Sorry to hear that you lost the fight. And that "better" doesn''t always win. For me "better" beats "ubiquitous" any time. Ah well, in time RSpec will gain a bigger and bigger share. It''s inevitable.> * RSpec is BDD (hand-waving new different troublesome); we do TDD. > We''ve covered that ground on this list many times; BDD is an extension > and interpretation of TDD, not some newfangled crackpot theory.Sigh. For me BDD *is* TDD, just with a vocabulary and a set of tools that subtly steer you towards doing it well rather than half-baked. Wincent
On 9/16/2007 10:18 AM, Kevin Williams wrote:> By all means, they should not ever try anything new. The people of > Earth should not have ever adopted the use of the electric light bulb > or the radio or the automobile or the airplane or the microwave or the > telephone or ... the Internet. No, don''t adopt anything new, just > stick to the old ways of doing things. It''s impossible for anyone to > improve on anything, right? Bah! Humbug!Obviously, I''m with you on that - but I wanted to make the point that, to make inroads in the greater community, "change is good" is not a good enough mantra! One of the problems is that, like templates (and yes, they''re still on erb, if you mean as opposed to HAML), you can''t really use RSpec for part of a project. There are no technical barriers; rspec and Test::Unit sit side-by-side quite nicely. But procedurally, organizationally, it''s a pain. And I don''t think there''s a way to ease that pain. A few more impressions from that meeting: * RSpec might be nice, but Test::Unit is the "least common denominator". We all know it, it works with everything, it''s there out of the box. RSpec doesn''t have enough compelling reasons to change to it. (Maybe an updated feature comparison would be good here, once 1.1 launches w/StoryRunner and perhaps these HTML Formatter changes.) * I mentioned how Test::Unit development had stagnated, and they took a different view of it: Test::Unit is "complete". It''s done, it works, it provides a base level of functionality that doesn''t need any more updating. Jay
In case it helps those who want to make it a little easier to try both at the same time (i.e. a bridge), ReinH has got a script that helps use autotest growl with both Test::Unit and RSpec: http://reinh.com/2007/9/12/the-autotest-rosetta-stone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070916/29a37e9b/attachment.html
I honestly didn''t understand what I was testing for when I was using TDD. I can''t imagine starting a project without using rspec. Rspec reads much clearly and keeps me in scope. The same reason I can''t imagine starting a project without ruby. Freedom is Slavery! On 9/16/07, David James <davidj503 at gmail.com> wrote:> > In case it helps those who want to make it a little easier to try both at > the same time (i.e. a bridge), ReinH has got a script that helps use > autotest growl with both Test::Unit and RSpec: > http://reinh.com/2007/9/12/the-autotest-rosetta-stone > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070916/ead920e6/attachment-0001.html
You may have lost the fight, but you didn''t lose the war. On 9/16/07, Andrew WC Brown <omen.king at gmail.com> wrote:> > I honestly didn''t understand what I was testing for when I was using TDD. > I can''t imagine starting a project without using rspec. > Rspec reads much clearly and keeps me in scope. > The same reason I can''t imagine starting a project without ruby. > > Freedom is Slavery! > > On 9/16/07, David James <davidj503 at gmail.com> wrote: > > > > In case it helps those who want to make it a little easier to try both > > at the same time (i.e. a bridge), ReinH has got a script that helps use > > autotest growl with both Test::Unit and RSpec: > > http://reinh.com/2007/9/12/the-autotest-rosetta-stone > > > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070916/fe928057/attachment.html
On 9/16/07, Jay Levitt <lists-rspec at shopwatch.org> wrote:> I''ve been working on a Rails project with one other developer; he was > using Test::Unit, and I was using RSpec. That works OK for a while, but > obviously it starts causing pain when you have to check in two places to > see if a piece of code is properly tested/spec''d, you can''t use TextMate > shortcuts to switch back and forth between code and test, you have to > duplicate shared behaviors/test helpers, etc. > > So when we brought in a consulting team to add some manpower, we > realized we had to switch to a single framework. This is a team that''s > fairly experienced with Rails and active in the Rails community, but was > quite opposed to choosing RSpec. > > Here are the arguments I heard against unifying on RSpec: > > * Test::Unit is ubiquitous. Everyone knows it. This is hard to > counter; it comes with Rails and is the default. Same reason many > people use Prototype even though JQuery/dojo might suit them better. > > * For that reason, it''s a lot easier to find examples of "how to do > something" in Test::Unit than in RSpec. That''s true; several times I''ve > had a bit of code that didn''t fall nicely into the MVC hierarchy, and I > wasn''t sure how to build up the right context to test it in. If I were > using Test::Unit, I could just copy the equivalent tests from Rails > core, but using RSpec I had to roll my own. > > * RSpec is BDD (hand-waving new different troublesome); we do TDD. > We''ve covered that ground on this list many times; BDD is an extension > and interpretation of TDD, not some newfangled crackpot theory. But > people don''t know that. > > * The team had in fact investigated RSpec a few months ago, and decided > they didn''t like it. Some of what they didn''t like has been fixed in > 1.0, but of course people aren''t going to come running to re-examine > each release, so the bitter taste remained: > > * #context was defined on Kernel. Not sure if that''s still true for > #describe. > > * Not compatible with tools that expect Test::Unit output. This > would(could) be fixed with the runner integration that''s been discussed. > > * Wasn''t compatible with mocha/FlexMock. Fixed now. > > But again, it came back to ubiquity, which is a pretty hard problem to > overcome. > > Seems to me that the best way to get RSpec adopted is to find some more > visible, prolific plugin programmers and evangelize them to start using > RSpec, so it''s not some "neat fringe thing", but a solid, respectable > alternative to Test::Unit. > > Jay Levitt > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >Bummer. Since you''ve been doing TDD the right way this whole time, hopefully you''ll be able to maintain (and teach) what you''ve learned. It might be uncomfortable or painful at first but I''m sure you can do it. I''m interested to know how your Test::Unit style might have changed after using RSpec for a while. I''m also interested to know if you "slip" back to your older, different style (if there was one). Pat
On Sep 16, 2007, at 9:38 AM, Jay Levitt wrote:> I''ve been working on a Rails project with one other developer; he was > using Test::Unit, and I was using RSpec. That works OK for a > while, but > obviously it starts causing pain when you have to check in two > places to > see if a piece of code is properly tested/spec''d, you can''t use > TextMate > shortcuts to switch back and forth between code and test, you have to > duplicate shared behaviors/test helpers, etc.There are two developers currently on the project I''m working on. I was lucky enough to win it for two reasons: 1. I had written 100 specs before the other developer came on. There were 60 Test::Unit tests, and half of them were failing. 2. The docs are the real winner. Generate the HTML specdoc report for a buisness user who understands the details of the app. He will appreciate it, understand what *has* been tested, what has not *yet* been tested (or, better yet, what *has* been built, and what is still TODO, or pending). Test::Unit cannot show that, so when you say to the client "I want to spend some time testing," it doesn''t translate into anything tangible for him. Plus, the specdoc is pretty! Scott
Test/spec + mocha On Sep 16, 2007, at 8:44 AM, "Pat Maddox" <pergesu at gmail.com> wrote:> On 9/16/07, Jay Levitt <lists-rspec at shopwatch.org> wrote: >> I''ve been working on a Rails project with one other developer; he was >> using Test::Unit, and I was using RSpec. That works OK for a >> while, but >> obviously it starts causing pain when you have to check in two >> places to >> see if a piece of code is properly tested/spec''d, you can''t use >> TextMate >> shortcuts to switch back and forth between code and test, you have to >> duplicate shared behaviors/test helpers, etc. >> >> So when we brought in a consulting team to add some manpower, we >> realized we had to switch to a single framework. This is a team >> that''s >> fairly experienced with Rails and active in the Rails community, >> but was >> quite opposed to choosing RSpec. >> >> Here are the arguments I heard against unifying on RSpec: >> >> * Test::Unit is ubiquitous. Everyone knows it. This is hard to >> counter; it comes with Rails and is the default. Same reason many >> people use Prototype even though JQuery/dojo might suit them better. >> >> * For that reason, it''s a lot easier to find examples of "how to do >> something" in Test::Unit than in RSpec. That''s true; several times >> I''ve >> had a bit of code that didn''t fall nicely into the MVC hierarchy, >> and I >> wasn''t sure how to build up the right context to test it in. If I >> were >> using Test::Unit, I could just copy the equivalent tests from Rails >> core, but using RSpec I had to roll my own. >> >> * RSpec is BDD (hand-waving new different troublesome); we do TDD. >> We''ve covered that ground on this list many times; BDD is an >> extension >> and interpretation of TDD, not some newfangled crackpot theory. But >> people don''t know that. >> >> * The team had in fact investigated RSpec a few months ago, and >> decided >> they didn''t like it. Some of what they didn''t like has been fixed in >> 1.0, but of course people aren''t going to come running to re-examine >> each release, so the bitter taste remained: >> >> * #context was defined on Kernel. Not sure if that''s still true for >> #describe. >> >> * Not compatible with tools that expect Test::Unit output. This >> would(could) be fixed with the runner integration that''s been >> discussed. >> >> * Wasn''t compatible with mocha/FlexMock. Fixed now. >> >> But again, it came back to ubiquity, which is a pretty hard problem >> to >> overcome. >> >> Seems to me that the best way to get RSpec adopted is to find some >> more >> visible, prolific plugin programmers and evangelize them to start >> using >> RSpec, so it''s not some "neat fringe thing", but a solid, respectable >> alternative to Test::Unit. >> >> Jay Levitt >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > Bummer. > > Since you''ve been doing TDD the right way this whole time, hopefully > you''ll be able to maintain (and teach) what you''ve learned. It might > be uncomfortable or painful at first but I''m sure you can do it. > > I''m interested to know how your Test::Unit style might have changed > after using RSpec for a while. I''m also interested to know if you > "slip" back to your older, different style (if there was one). > > Pat > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
> * I mentioned how Test::Unit development had stagnated, and they took a > different view of it: Test::Unit is "complete". It''s done, it works, > it provides a base level of functionality that doesn''t need any more > updating.That''s quite troubling in my opinion for a developer(s) to say that something is complete and doesn''t need any more updating. That would be a red flag for me in how this team may operate. -- - Robert http://robertrevans.com http://rubysnips.com