I like Shoulda. Sometimes I like plain old Test::Unit. Cucumber gives me a different thought process. I''d just like to hear some thoughts on why RSpec? What does it buy me that I can''t get with Shoulda? I just can''t seem to think in RSpec. Where is there a good example of RSpec tests that will help me grasp the right path? Thanks! -- Amos King http://dirtyInformation.com http://github.com/Adkron -- Looking for something to do? Visit http://ImThere.com
I am also having same question that i can''t find the reason why i should go for RSpec instead of Test/Unit. There is no compelling reason / advantage offered by RSpec except semantics. Is RSpec all about different syntax??????? Thanks in advance for clarifying it???
I wasn''t thinking about a gun. I was just wondering if there is some underlying reason that I''m missing. Is there a background structure that I''m not grasping? Is there a huge piece of functionality that I''m missing? Is it faster than Test:Unit or Shoulda? Amos(adkron) On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023 at gmail.com> wrote:> I think it''s that RSpec encodes some of the latest BDD into its way of > thinking. > It has a vocabulary that encourages that, so in a way, yes, it''s all about > semantics. > Semantics that encourage agile thinking & practice. > Also, it allows you to structure your specs (that become your regression > tests) in a much more intuitive way than Test::Unit -- I don''t know Shoulda. > But if I understood all the pros & cons of two systems & preferred another, > I''d use that -- there''s no gun against anyone''s head. ;) > ?? Doug. > > 2009/4/22 Saturn <saturn.sting at gmail.com> >> >> I am also having same question that i can''t find the reason why i >> should go for RSpec instead of Test/Unit. >> There is no compelling reason / advantage offered by RSpec except >> semantics. >> >> >> Is RSpec all about different syntax??????? >> >> Thanks in advance for clarifying it??? >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- Amos King http://dirtyInformation.com http://github.com/Adkron -- Looking for something to do? Visit http://ImThere.com
Amos King wrote:> I like Shoulda. Sometimes I like plain old Test::Unit. Cucumber > gives me a different thought process. > > I''d just like to hear some thoughts on why RSpec? What does it buy me > that I can''t get with Shoulda? I just can''t seem to think in RSpec. > Where is there a good example of RSpec tests that will help me grasp > the right path?RSpec is not DRY with respect to Test::Unit. A bit of "not invented here". RSpec''s original incarnation should have been like test-spec. I suspect new syntax built within Test::Unit would have save us from tedious hours of reinventing all the test fixtures (such as the mock @request and @response for Rails). The only design point for the new syntax I can see is this: context ''general'' do setup{ general } specify{ something general } specify{ another general thing } context ''specific'' do setup{ specific } specify{ test general and specific together } specify{ test specific and general together! } end end The alternative in TestCase was only either a setup() that builds both ''general'' and ''specific'', when two cases don''t need it, or duplicating ''specific'' into two test cases, or merging the ''specific'' setup into a global ''assemble_specific'' method yadda yadda yadda. Nesting the contexts lets them share their setups, so the contexts are much easier to mix and match. -- Phlip http://flea.sourceforge.net/resume.html
On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king at gmail.com> wrote:> I wasn''t thinking about a gun. ?I was just wondering if there is some > underlying reason that I''m missing. ?Is there a background structure > that I''m not grasping? ?Is there a huge piece of functionality that > I''m missing? ?Is it faster than Test:Unit or Shoulda?RSpec is not just about RSpec. It''s about BDD. It''s about encouraging conversation about testing and looking at it in different ways. It''s about illuminating the design, specification, collaboration and documentation aspects of tests, and thinking of them as executable examples of behaviour. You can do this all without RSpec, but RSpec aims to help with innovations like: * strings as example group names * strings as example names * pending examples * nested groups for flexible organization * should[_not] + matchers (inspired by hamcrest - a java library) * one matcher supports both positive and negative expectations * improved failure messages * flexible/readable/customizable output formats * built-in mocking framework * plain text scenarios (now in Cucumber) Specifically with Rails: * component isolation. ZenTest offered separate test cases for models/views/helpers/controllers before RSpec, and RSpec extended the idea by allowing you to run controller examples with no dependency on views and vice versa. Some folks get nervous with that sort of isolation, but, generally, folks coming to Ruby from a background in TDD with Java or .NET are all over it. That''s not the full list, but a good overview. You can get some of these things from other frameworks, but they almost all originated in RSpec, which has been and will continue to be a center of innovation in testing in Ruby since its creation in 2005. To be clear, it is certainly not the only center of innovation. Shoulda brought us macros, which are great, and we''ve made it easier to write your own in RSpec, and now you can use shoulda matchers right in RSpec. Micronaut adds a tagging system that allows you to group examples together in different ways. This is definitely something we''ll be adding to RSpec sooner or later. Ryan Davis and Eric Hodel continue to bring us game-changing testing tools like autotest, heckle, flog, and flay. RSpec has been around for nearly 4 years now. It has matured quite a bit, and continues to do so. A twitter poll back in January suggests that the majority of people doing testing in Ruby are using RSpec: http://twtpoll.com/r/zhh2fm. Note that this poll pits RSpec against all other frameworks and it still gets the majority. Polls are polls, and in a community of over a million Ruby developers, it''s hard (for me) to believe in the accuracy of a poll that 680ish ppl voted in. But hey, that''s 360-ish ppl who are at least willing to say they use rspec, so at least we know that much :) The point being that with a lot of users comes a lot of mindshare. And as RSpec continues to mature and become easier to contribute to, that mindshare will grow. More and more extension libraries like rspec_on_rails_on_crack and remarkable will emerge, and RSpec will get better and better at supporting them. It won''t be long before "rspec OR test/unit" becomes a false choice, and you''ll be able to seamlessly use both in a unified suite. This is already largely the case, but it will get better. And let''s not forget http://rubyspec.org/ As for which tools to use, you should use the ones that make you happy and make your job and life easier. If there is something that you like about shoulda over rspec, then use shoulda. If prefer kickin'' it old school, stick w/ test/unit or minitest. Regardless of the tools you use, I''d recommend that you pay attention to RSpec and its community. There is a lot of action here. I''d also recommend that you read The RSpec Book. While the material in the book is taught through RSpec, and much of the book is very RSpec-specific, there is quite a bit of exploration of the process of BDD that can be applied regardless of toolset. Not to mention introduction to other tools like Cucumber, Webrat and Selenium. Thanks for the thought provoking question. I''ve been involved with RSpec since shortly after its creation in 2005, and I sometimes lose sight of why I got into it and why I stay with it. This has been a helpful reminder to me, and I hope you find my ramblings helpful to you. Cheers, David> > Amos(adkron) > > On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023 at gmail.com> wrote: >> I think it''s that RSpec encodes some of the latest BDD into its way of >> thinking. >> It has a vocabulary that encourages that, so in a way, yes, it''s all about >> semantics. >> Semantics that encourage agile thinking & practice. >> Also, it allows you to structure your specs (that become your regression >> tests) in a much more intuitive way than Test::Unit -- I don''t know Shoulda. >> But if I understood all the pros & cons of two systems & preferred another, >> I''d use that -- there''s no gun against anyone''s head. ;) >> ?? Doug. >> >> 2009/4/22 Saturn <saturn.sting at gmail.com> >>> >>> I am also having same question that i can''t find the reason why i >>> should go for RSpec instead of Test/Unit. >>> There is no compelling reason / advantage offered by RSpec except >>> semantics. >>> >>> >>> Is RSpec all about different syntax??????? >>> >>> Thanks in advance for clarifying it??? >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > > > -- > Amos King > http://dirtyInformation.com > http://github.com/Adkron > -- > Looking for something to do? Visit http://ImThere.com > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On Wed, Apr 22, 2009 at 9:03 AM, Phlip <phlip2005 at gmail.com> wrote:> Amos King wrote: >> >> I like Shoulda. ?Sometimes I like plain old Test::Unit. ?Cucumber >> gives me a different thought process. >> >> I''d just like to hear some thoughts on why RSpec? ?What does it buy me >> that I can''t get with Shoulda? ?I just can''t seem to think in RSpec. >> Where is there a good example of RSpec tests that will help me grasp >> the right path? > > RSpec is not DRY with respect to Test::Unit. A bit of "not invented here".Agreed. That''s partially resolved now and will be more fully resolved in the not-to-distant-future.> RSpec''s original incarnation should have been like test-spec.In terms of the runner, yes.> I suspect new > syntax built within Test::Unit would have save us from tedious hours of > reinventing all the test fixtures (such as the mock @request and @response > for Rails).Not sure what you mean here. RSpec interops w/ t/u. You can do that explicitly outside rails, and it''s implicit in rails. RSpec''s manipulation of test request/response in rails is there to support component isolation, which rails does not.> The only design point for the new syntax I can see is this: > > ? context ''general'' do > ? ? setup{ general } > ? ? specify{ something general } > ? ? specify{ another general thing } > ? ? context ''specific'' do > ? ? ? setup{ specific } > ? ? ? specify{ test general and specific together } > ? ? ? specify{ test specific and general together! } > ? ? end > ? end > > The alternative in TestCase was only either a setup() that builds both > ''general'' > and ''specific'', when two cases don''t need it, or duplicating ''specific'' into > two > test cases, or merging the ''specific'' setup into a global > ''assemble_specific'' > method yadda yadda yadda. Nesting the contexts lets them share their setups, > so > the contexts are much easier to mix and match.It''s not just about syntax and structure. It''s also about process. Better failure messages, pending examples, and customizable output are all things that aim to make it easier to develop software. Cheers, David> > -- > ?Phlip > ?http://flea.sourceforge.net/resume.html > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
Thanks, David. I do often read the rspec list because of the discussions that you site. The community maybe enough for me to make the jump. I can''t wait to be able to use RSpec and Test::Unit together as a single cohesive framework. I''ll keep working my side project with RSpec and see what ideas I can come up with. At work I will continue to use Shoulda, Test::Unit, and Webrat. We''ll see what ideas can be ported around. I''ll also take a look at the book. I''ve worked on Webrat::Selenium and grid support a bit so let''s see where this can take me. Thanks for the ideas from everyone, and you''ve all encouraged me to take a deeper look. Amos(adkron) On Wed, Apr 22, 2009 at 9:08 AM, David Chelimsky <dchelimsky at gmail.com> wrote:> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king at gmail.com> wrote: >> I wasn''t thinking about a gun. ?I was just wondering if there is some >> underlying reason that I''m missing. ?Is there a background structure >> that I''m not grasping? ?Is there a huge piece of functionality that >> I''m missing? ?Is it faster than Test:Unit or Shoulda? > > RSpec is not just about RSpec. It''s about BDD. It''s about encouraging > conversation about testing and looking at it in different ways. It''s > about illuminating the design, specification, collaboration and > documentation aspects of tests, and thinking of them as executable > examples of behaviour. You can do this all without RSpec, but RSpec > aims to help with innovations like: > > * strings as example group names > * strings as example names > * pending examples > * nested groups for flexible organization > * should[_not] + matchers (inspired by hamcrest - a java library) > ?* one matcher supports both positive and negative expectations > * improved failure messages > * flexible/readable/customizable output formats > * built-in mocking framework > * plain text scenarios (now in Cucumber) > > Specifically with Rails: > > * component isolation. ZenTest offered separate test cases for > models/views/helpers/controllers before RSpec, and RSpec extended the > idea by allowing you to run controller examples with no dependency on > views and vice versa. Some folks get nervous with that sort of > isolation, but, generally, folks coming to Ruby from a background in > TDD with Java or .NET are all over it. > > That''s not the full list, but a good overview. You can get some of > these things from other frameworks, but they almost all originated in > RSpec, which has been and will continue to be a center of innovation > in testing in Ruby since its creation in 2005. > > To be clear, it is certainly not the only center of innovation. > Shoulda brought us macros, which are great, and we''ve made it easier > to write your own in RSpec, and now you can use shoulda matchers right > in RSpec. > > Micronaut adds a tagging system that allows you to group examples > together in different ways. This is definitely something we''ll be > adding to RSpec sooner or later. > > Ryan Davis and Eric Hodel continue to bring us game-changing testing > tools like autotest, heckle, flog, and flay. > > RSpec has been around for nearly 4 years now. It has matured quite a > bit, and continues to do so. A twitter poll back in January suggests > that the majority of people doing testing in Ruby are using RSpec: > http://twtpoll.com/r/zhh2fm. Note that this poll pits RSpec against > all other frameworks and it still gets the majority. Polls are polls, > and in a community of over a million Ruby developers, it''s hard (for > me) to believe in the accuracy of a poll that 680ish ppl voted in. But > hey, that''s 360-ish ppl who are at least willing to say they use > rspec, so at least we know that much :) > > The point being that with a lot of users comes a lot of mindshare. And > as RSpec continues to mature and become easier to contribute to, that > mindshare will grow. More and more extension libraries like > rspec_on_rails_on_crack and remarkable will emerge, and RSpec will get > better and better at supporting them. It won''t be long before "rspec > OR test/unit" becomes a false choice, and you''ll be able to seamlessly > use both in a unified suite. This is already largely the case, but it > will get better. > > And let''s not forget http://rubyspec.org/ > > As for which tools to use, you should use the ones that make you happy > and make your job and life easier. If there is something that you like > about shoulda over rspec, then use shoulda. If prefer kickin'' it old > school, stick w/ test/unit or minitest. Regardless of the tools you > use, I''d recommend that you pay attention to RSpec and its community. > There is a lot of action here. > > I''d also recommend that you read The RSpec Book. While the material in > the book is taught through RSpec, and much of the book is very > RSpec-specific, there is quite a bit of exploration of the process of > BDD that can be applied regardless of toolset. Not to mention > introduction to other tools like Cucumber, Webrat and Selenium. > > Thanks for the thought provoking question. I''ve been involved with > RSpec since shortly after its creation in 2005, and I sometimes lose > sight of why I got into it and why I stay with it. This has been a > helpful reminder to me, and I hope you find my ramblings helpful to > you. > > Cheers, > David > >> >> Amos(adkron) >> >> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023 at gmail.com> wrote: >>> I think it''s that RSpec encodes some of the latest BDD into its way of >>> thinking. >>> It has a vocabulary that encourages that, so in a way, yes, it''s all about >>> semantics. >>> Semantics that encourage agile thinking & practice. >>> Also, it allows you to structure your specs (that become your regression >>> tests) in a much more intuitive way than Test::Unit -- I don''t know Shoulda. >>> But if I understood all the pros & cons of two systems & preferred another, >>> I''d use that -- there''s no gun against anyone''s head. ;) >>> ?? Doug. >>> >>> 2009/4/22 Saturn <saturn.sting at gmail.com> >>>> >>>> I am also having same question that i can''t find the reason why i >>>> should go for RSpec instead of Test/Unit. >>>> There is no compelling reason / advantage offered by RSpec except >>>> semantics. >>>> >>>> >>>> Is RSpec all about different syntax??????? >>>> >>>> Thanks in advance for clarifying it??? >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >> >> >> >> -- >> Amos King >> http://dirtyInformation.com >> http://github.com/Adkron >> -- >> Looking for something to do? Visit http://ImThere.com >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- Amos King http://dirtyInformation.com http://github.com/Adkron -- Looking for something to do? Visit http://ImThere.com
On Wed, Apr 22, 2009 at 7:28 AM, Amos King <amos.l.king at gmail.com> wrote:> Thanks, David. > > I do often read the rspec list because of the discussions that you > site. ?The community maybe enough for me to make the jump. ?I can''t > wait to be able to use RSpec and Test::Unit together as a single > cohesive framework. ?I''ll keep working my side project with RSpec and > see what ideas I can come up with. ?At work I will continue to use > Shoulda, Test::Unit, and Webrat. ?We''ll see what ideas can be ported > around. ?I''ll also take a look at the book.You can run test/unit & rspec together already. All you need to do is: require "spec/interop/test" before your spec definitions. Here is an example: http://gist.github.com/99895 The shoulda integration did not work, however> > I''ve worked on Webrat::Selenium and grid support a bit so let''s see > where this can take me. ?Thanks for the ideas from everyone, and > you''ve all encouraged me to take a deeper look. > > Amos(adkron) > > On Wed, Apr 22, 2009 at 9:08 AM, David Chelimsky <dchelimsky at gmail.com> wrote: >> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king at gmail.com> wrote: >>> I wasn''t thinking about a gun. ?I was just wondering if there is some >>> underlying reason that I''m missing. ?Is there a background structure >>> that I''m not grasping? ?Is there a huge piece of functionality that >>> I''m missing? ?Is it faster than Test:Unit or Shoulda? >> >> RSpec is not just about RSpec. It''s about BDD. It''s about encouraging >> conversation about testing and looking at it in different ways. It''s >> about illuminating the design, specification, collaboration and >> documentation aspects of tests, and thinking of them as executable >> examples of behaviour. You can do this all without RSpec, but RSpec >> aims to help with innovations like: >> >> * strings as example group names >> * strings as example names >> * pending examples >> * nested groups for flexible organization >> * should[_not] + matchers (inspired by hamcrest - a java library) >> ?* one matcher supports both positive and negative expectations >> * improved failure messages >> * flexible/readable/customizable output formats >> * built-in mocking framework >> * plain text scenarios (now in Cucumber) >> >> Specifically with Rails: >> >> * component isolation. ZenTest offered separate test cases for >> models/views/helpers/controllers before RSpec, and RSpec extended the >> idea by allowing you to run controller examples with no dependency on >> views and vice versa. Some folks get nervous with that sort of >> isolation, but, generally, folks coming to Ruby from a background in >> TDD with Java or .NET are all over it. >> >> That''s not the full list, but a good overview. You can get some of >> these things from other frameworks, but they almost all originated in >> RSpec, which has been and will continue to be a center of innovation >> in testing in Ruby since its creation in 2005. >> >> To be clear, it is certainly not the only center of innovation. >> Shoulda brought us macros, which are great, and we''ve made it easier >> to write your own in RSpec, and now you can use shoulda matchers right >> in RSpec. >> >> Micronaut adds a tagging system that allows you to group examples >> together in different ways. This is definitely something we''ll be >> adding to RSpec sooner or later. >> >> Ryan Davis and Eric Hodel continue to bring us game-changing testing >> tools like autotest, heckle, flog, and flay. >> >> RSpec has been around for nearly 4 years now. It has matured quite a >> bit, and continues to do so. A twitter poll back in January suggests >> that the majority of people doing testing in Ruby are using RSpec: >> http://twtpoll.com/r/zhh2fm. Note that this poll pits RSpec against >> all other frameworks and it still gets the majority. Polls are polls, >> and in a community of over a million Ruby developers, it''s hard (for >> me) to believe in the accuracy of a poll that 680ish ppl voted in. But >> hey, that''s 360-ish ppl who are at least willing to say they use >> rspec, so at least we know that much :) >> >> The point being that with a lot of users comes a lot of mindshare. And >> as RSpec continues to mature and become easier to contribute to, that >> mindshare will grow. More and more extension libraries like >> rspec_on_rails_on_crack and remarkable will emerge, and RSpec will get >> better and better at supporting them. It won''t be long before "rspec >> OR test/unit" becomes a false choice, and you''ll be able to seamlessly >> use both in a unified suite. This is already largely the case, but it >> will get better. >> >> And let''s not forget http://rubyspec.org/ >> >> As for which tools to use, you should use the ones that make you happy >> and make your job and life easier. If there is something that you like >> about shoulda over rspec, then use shoulda. If prefer kickin'' it old >> school, stick w/ test/unit or minitest. Regardless of the tools you >> use, I''d recommend that you pay attention to RSpec and its community. >> There is a lot of action here. >> >> I''d also recommend that you read The RSpec Book. While the material in >> the book is taught through RSpec, and much of the book is very >> RSpec-specific, there is quite a bit of exploration of the process of >> BDD that can be applied regardless of toolset. Not to mention >> introduction to other tools like Cucumber, Webrat and Selenium. >> >> Thanks for the thought provoking question. I''ve been involved with >> RSpec since shortly after its creation in 2005, and I sometimes lose >> sight of why I got into it and why I stay with it. This has been a >> helpful reminder to me, and I hope you find my ramblings helpful to >> you. >> >> Cheers, >> David >> >>> >>> Amos(adkron) >>> >>> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023 at gmail.com> wrote: >>>> I think it''s that RSpec encodes some of the latest BDD into its way of >>>> thinking. >>>> It has a vocabulary that encourages that, so in a way, yes, it''s all about >>>> semantics. >>>> Semantics that encourage agile thinking & practice. >>>> Also, it allows you to structure your specs (that become your regression >>>> tests) in a much more intuitive way than Test::Unit -- I don''t know Shoulda. >>>> But if I understood all the pros & cons of two systems & preferred another, >>>> I''d use that -- there''s no gun against anyone''s head. ;) >>>> ?? Doug. >>>> >>>> 2009/4/22 Saturn <saturn.sting at gmail.com> >>>>> >>>>> I am also having same question that i can''t find the reason why i >>>>> should go for RSpec instead of Test/Unit. >>>>> There is no compelling reason / advantage offered by RSpec except >>>>> semantics. >>>>> >>>>> >>>>> Is RSpec all about different syntax??????? >>>>> >>>>> Thanks in advance for clarifying it??? >>>>> _______________________________________________ >>>>> rspec-users mailing list >>>>> rspec-users at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>> >>>> >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>> >>> >>> >>> >>> -- >>> Amos King >>> http://dirtyInformation.com >>> http://github.com/Adkron >>> -- >>> Looking for something to do? Visit http://ImThere.com >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > > > -- > Amos King > http://dirtyInformation.com > http://github.com/Adkron > -- > Looking for something to do? Visit http://ImThere.com > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On Wed, Apr 22, 2009 at 9:34 AM, Brian Takita <brian.takita at gmail.com> wrote:> On Wed, Apr 22, 2009 at 7:28 AM, Amos King <amos.l.king at gmail.com> wrote: >> Thanks, David. >> >> I do often read the rspec list because of the discussions that you >> site. ?The community maybe enough for me to make the jump. ?I can''t >> wait to be able to use RSpec and Test::Unit together as a single >> cohesive framework. ?I''ll keep working my side project with RSpec and >> see what ideas I can come up with. ?At work I will continue to use >> Shoulda, Test::Unit, and Webrat. ?We''ll see what ideas can be ported >> around. ?I''ll also take a look at the book. > You can run test/unit & rspec together already. > > All you need to do is: > require "spec/interop/test" > before your spec definitions. > > Here is an example: > http://gist.github.com/99895 > > The shoulda integration did not work, howeverWhat do you think of having ExampleGroup.should create an Example?>> >> I''ve worked on Webrat::Selenium and grid support a bit so let''s see >> where this can take me. ?Thanks for the ideas from everyone, and >> you''ve all encouraged me to take a deeper look. >> >> Amos(adkron) >> >> On Wed, Apr 22, 2009 at 9:08 AM, David Chelimsky <dchelimsky at gmail.com> wrote: >>> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king at gmail.com> wrote: >>>> I wasn''t thinking about a gun. ?I was just wondering if there is some >>>> underlying reason that I''m missing. ?Is there a background structure >>>> that I''m not grasping? ?Is there a huge piece of functionality that >>>> I''m missing? ?Is it faster than Test:Unit or Shoulda? >>> >>> RSpec is not just about RSpec. It''s about BDD. It''s about encouraging >>> conversation about testing and looking at it in different ways. It''s >>> about illuminating the design, specification, collaboration and >>> documentation aspects of tests, and thinking of them as executable >>> examples of behaviour. You can do this all without RSpec, but RSpec >>> aims to help with innovations like: >>> >>> * strings as example group names >>> * strings as example names >>> * pending examples >>> * nested groups for flexible organization >>> * should[_not] + matchers (inspired by hamcrest - a java library) >>> ?* one matcher supports both positive and negative expectations >>> * improved failure messages >>> * flexible/readable/customizable output formats >>> * built-in mocking framework >>> * plain text scenarios (now in Cucumber) >>> >>> Specifically with Rails: >>> >>> * component isolation. ZenTest offered separate test cases for >>> models/views/helpers/controllers before RSpec, and RSpec extended the >>> idea by allowing you to run controller examples with no dependency on >>> views and vice versa. Some folks get nervous with that sort of >>> isolation, but, generally, folks coming to Ruby from a background in >>> TDD with Java or .NET are all over it. >>> >>> That''s not the full list, but a good overview. You can get some of >>> these things from other frameworks, but they almost all originated in >>> RSpec, which has been and will continue to be a center of innovation >>> in testing in Ruby since its creation in 2005. >>> >>> To be clear, it is certainly not the only center of innovation. >>> Shoulda brought us macros, which are great, and we''ve made it easier >>> to write your own in RSpec, and now you can use shoulda matchers right >>> in RSpec. >>> >>> Micronaut adds a tagging system that allows you to group examples >>> together in different ways. This is definitely something we''ll be >>> adding to RSpec sooner or later. >>> >>> Ryan Davis and Eric Hodel continue to bring us game-changing testing >>> tools like autotest, heckle, flog, and flay. >>> >>> RSpec has been around for nearly 4 years now. It has matured quite a >>> bit, and continues to do so. A twitter poll back in January suggests >>> that the majority of people doing testing in Ruby are using RSpec: >>> http://twtpoll.com/r/zhh2fm. Note that this poll pits RSpec against >>> all other frameworks and it still gets the majority. Polls are polls, >>> and in a community of over a million Ruby developers, it''s hard (for >>> me) to believe in the accuracy of a poll that 680ish ppl voted in. But >>> hey, that''s 360-ish ppl who are at least willing to say they use >>> rspec, so at least we know that much :) >>> >>> The point being that with a lot of users comes a lot of mindshare. And >>> as RSpec continues to mature and become easier to contribute to, that >>> mindshare will grow. More and more extension libraries like >>> rspec_on_rails_on_crack and remarkable will emerge, and RSpec will get >>> better and better at supporting them. It won''t be long before "rspec >>> OR test/unit" becomes a false choice, and you''ll be able to seamlessly >>> use both in a unified suite. This is already largely the case, but it >>> will get better. >>> >>> And let''s not forget http://rubyspec.org/ >>> >>> As for which tools to use, you should use the ones that make you happy >>> and make your job and life easier. If there is something that you like >>> about shoulda over rspec, then use shoulda. If prefer kickin'' it old >>> school, stick w/ test/unit or minitest. Regardless of the tools you >>> use, I''d recommend that you pay attention to RSpec and its community. >>> There is a lot of action here. >>> >>> I''d also recommend that you read The RSpec Book. While the material in >>> the book is taught through RSpec, and much of the book is very >>> RSpec-specific, there is quite a bit of exploration of the process of >>> BDD that can be applied regardless of toolset. Not to mention >>> introduction to other tools like Cucumber, Webrat and Selenium. >>> >>> Thanks for the thought provoking question. I''ve been involved with >>> RSpec since shortly after its creation in 2005, and I sometimes lose >>> sight of why I got into it and why I stay with it. This has been a >>> helpful reminder to me, and I hope you find my ramblings helpful to >>> you. >>> >>> Cheers, >>> David >>> >>>> >>>> Amos(adkron) >>>> >>>> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023 at gmail.com> wrote: >>>>> I think it''s that RSpec encodes some of the latest BDD into its way of >>>>> thinking. >>>>> It has a vocabulary that encourages that, so in a way, yes, it''s all about >>>>> semantics. >>>>> Semantics that encourage agile thinking & practice. >>>>> Also, it allows you to structure your specs (that become your regression >>>>> tests) in a much more intuitive way than Test::Unit -- I don''t know Shoulda. >>>>> But if I understood all the pros & cons of two systems & preferred another, >>>>> I''d use that -- there''s no gun against anyone''s head. ;) >>>>> ?? Doug. >>>>> >>>>> 2009/4/22 Saturn <saturn.sting at gmail.com> >>>>>> >>>>>> I am also having same question that i can''t find the reason why i >>>>>> should go for RSpec instead of Test/Unit. >>>>>> There is no compelling reason / advantage offered by RSpec except >>>>>> semantics. >>>>>> >>>>>> >>>>>> Is RSpec all about different syntax??????? >>>>>> >>>>>> Thanks in advance for clarifying it??? >>>>>> _______________________________________________ >>>>>> rspec-users mailing list >>>>>> rspec-users at rubyforge.org >>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>> >>>>> >>>>> _______________________________________________ >>>>> rspec-users mailing list >>>>> rspec-users at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>> >>>> >>>> >>>> >>>> -- >>>> Amos King >>>> http://dirtyInformation.com >>>> http://github.com/Adkron >>>> -- >>>> Looking for something to do? Visit http://ImThere.com >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >> >> >> >> -- >> Amos King >> http://dirtyInformation.com >> http://github.com/Adkron >> -- >> Looking for something to do? Visit http://ImThere.com >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >
On Wed, Apr 22, 2009 at 11:34 AM, Brian Takita <brian.takita at gmail.com> wrote:> On Wed, Apr 22, 2009 at 7:28 AM, Amos King <amos.l.king at gmail.com> wrote: >> Thanks, David. >> >> I do often read the rspec list because of the discussions that you >> site. ?The community maybe enough for me to make the jump. ?I can''t >> wait to be able to use RSpec and Test::Unit together as a single >> cohesive framework. ?I''ll keep working my side project with RSpec and >> see what ideas I can come up with. ?At work I will continue to use >> Shoulda, Test::Unit, and Webrat. ?We''ll see what ideas can be ported >> around. ?I''ll also take a look at the book. > You can run test/unit & rspec together already. > > All you need to do is: > require "spec/interop/test"With rspec 1.2.2 you can require "spec/test/unit''.> before your spec definitions. > > Here is an example: > http://gist.github.com/99895 > > The shoulda integration did not work, howeverI haven''t looked, but I''ll bet rspec and shoulda are doing some of the same monkey patching of test/unit. You can use shoulda matchers in rspec without the rest of shoulda''s infrastructure if you want to. That gives you rspec structure + terse expressions like this: describe Person do it { should require_attributes(:email) } end If you prefer to use shoulda for structure, I *think* you can incorporate rspec''s matchers in shoulda like this: require ''shoulda'' require ''spec/expectations'' class Test::Unit::TestCase include Spec::Matchers end Haven''t tried it, but I don''t see why it wouldn''t work.>> >> I''ve worked on Webrat::Selenium and grid support a bit so let''s see >> where this can take me. ?Thanks for the ideas from everyone, and >> you''ve all encouraged me to take a deeper look. >> >> Amos(adkron) >> >> On Wed, Apr 22, 2009 at 9:08 AM, David Chelimsky <dchelimsky at gmail.com> wrote: >>> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king at gmail.com> wrote: >>>> I wasn''t thinking about a gun. ?I was just wondering if there is some >>>> underlying reason that I''m missing. ?Is there a background structure >>>> that I''m not grasping? ?Is there a huge piece of functionality that >>>> I''m missing? ?Is it faster than Test:Unit or Shoulda? >>> >>> RSpec is not just about RSpec. It''s about BDD. It''s about encouraging >>> conversation about testing and looking at it in different ways. It''s >>> about illuminating the design, specification, collaboration and >>> documentation aspects of tests, and thinking of them as executable >>> examples of behaviour. You can do this all without RSpec, but RSpec >>> aims to help with innovations like: >>> >>> * strings as example group names >>> * strings as example names >>> * pending examples >>> * nested groups for flexible organization >>> * should[_not] + matchers (inspired by hamcrest - a java library) >>> ?* one matcher supports both positive and negative expectations >>> * improved failure messages >>> * flexible/readable/customizable output formats >>> * built-in mocking framework >>> * plain text scenarios (now in Cucumber) >>> >>> Specifically with Rails: >>> >>> * component isolation. ZenTest offered separate test cases for >>> models/views/helpers/controllers before RSpec, and RSpec extended the >>> idea by allowing you to run controller examples with no dependency on >>> views and vice versa. Some folks get nervous with that sort of >>> isolation, but, generally, folks coming to Ruby from a background in >>> TDD with Java or .NET are all over it. >>> >>> That''s not the full list, but a good overview. You can get some of >>> these things from other frameworks, but they almost all originated in >>> RSpec, which has been and will continue to be a center of innovation >>> in testing in Ruby since its creation in 2005. >>> >>> To be clear, it is certainly not the only center of innovation. >>> Shoulda brought us macros, which are great, and we''ve made it easier >>> to write your own in RSpec, and now you can use shoulda matchers right >>> in RSpec. >>> >>> Micronaut adds a tagging system that allows you to group examples >>> together in different ways. This is definitely something we''ll be >>> adding to RSpec sooner or later. >>> >>> Ryan Davis and Eric Hodel continue to bring us game-changing testing >>> tools like autotest, heckle, flog, and flay. >>> >>> RSpec has been around for nearly 4 years now. It has matured quite a >>> bit, and continues to do so. A twitter poll back in January suggests >>> that the majority of people doing testing in Ruby are using RSpec: >>> http://twtpoll.com/r/zhh2fm. Note that this poll pits RSpec against >>> all other frameworks and it still gets the majority. Polls are polls, >>> and in a community of over a million Ruby developers, it''s hard (for >>> me) to believe in the accuracy of a poll that 680ish ppl voted in. But >>> hey, that''s 360-ish ppl who are at least willing to say they use >>> rspec, so at least we know that much :) >>> >>> The point being that with a lot of users comes a lot of mindshare. And >>> as RSpec continues to mature and become easier to contribute to, that >>> mindshare will grow. More and more extension libraries like >>> rspec_on_rails_on_crack and remarkable will emerge, and RSpec will get >>> better and better at supporting them. It won''t be long before "rspec >>> OR test/unit" becomes a false choice, and you''ll be able to seamlessly >>> use both in a unified suite. This is already largely the case, but it >>> will get better. >>> >>> And let''s not forget http://rubyspec.org/ >>> >>> As for which tools to use, you should use the ones that make you happy >>> and make your job and life easier. If there is something that you like >>> about shoulda over rspec, then use shoulda. If prefer kickin'' it old >>> school, stick w/ test/unit or minitest. Regardless of the tools you >>> use, I''d recommend that you pay attention to RSpec and its community. >>> There is a lot of action here. >>> >>> I''d also recommend that you read The RSpec Book. While the material in >>> the book is taught through RSpec, and much of the book is very >>> RSpec-specific, there is quite a bit of exploration of the process of >>> BDD that can be applied regardless of toolset. Not to mention >>> introduction to other tools like Cucumber, Webrat and Selenium. >>> >>> Thanks for the thought provoking question. I''ve been involved with >>> RSpec since shortly after its creation in 2005, and I sometimes lose >>> sight of why I got into it and why I stay with it. This has been a >>> helpful reminder to me, and I hope you find my ramblings helpful to >>> you. >>> >>> Cheers, >>> David >>> >>>> >>>> Amos(adkron) >>>> >>>> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023 at gmail.com> wrote: >>>>> I think it''s that RSpec encodes some of the latest BDD into its way of >>>>> thinking. >>>>> It has a vocabulary that encourages that, so in a way, yes, it''s all about >>>>> semantics. >>>>> Semantics that encourage agile thinking & practice. >>>>> Also, it allows you to structure your specs (that become your regression >>>>> tests) in a much more intuitive way than Test::Unit -- I don''t know Shoulda. >>>>> But if I understood all the pros & cons of two systems & preferred another, >>>>> I''d use that -- there''s no gun against anyone''s head. ;) >>>>> ?? Doug. >>>>> >>>>> 2009/4/22 Saturn <saturn.sting at gmail.com> >>>>>> >>>>>> I am also having same question that i can''t find the reason why i >>>>>> should go for RSpec instead of Test/Unit. >>>>>> There is no compelling reason / advantage offered by RSpec except >>>>>> semantics. >>>>>> >>>>>> >>>>>> Is RSpec all about different syntax??????? >>>>>> >>>>>> Thanks in advance for clarifying it??? >>>>>> _______________________________________________ >>>>>> rspec-users mailing list >>>>>> rspec-users at rubyforge.org >>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>> >>>>> >>>>> _______________________________________________ >>>>> rspec-users mailing list >>>>> rspec-users at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>> >>>> >>>> >>>> >>>> -- >>>> Amos King >>>> http://dirtyInformation.com >>>> http://github.com/Adkron >>>> -- >>>> Looking for something to do? Visit http://ImThere.com >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >> >> >> >> -- >> Amos King >> http://dirtyInformation.com >> http://github.com/Adkron >> -- >> Looking for something to do? Visit http://ImThere.com >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Apr 22, 2009, at 4:25 AM, Amos King wrote:> I wasn''t thinking about a gun. I was just wondering if there is some > underlying reason that I''m missing. Is there a background structure > that I''m not grasping? Is there a huge piece of functionality that > I''m missing? Is it faster than Test:Unit or Shoulda? > > Amos(adkron)Personally, I can''t think of one single huge piece of functionality that makes RSpec win over TestUnit, but it''s a whole bunch of little things. It can be faster if you make use of mocks/stubs, and separation between layers: you can test your controllers without having to render the views. Shoulda is good too. It adds some of the features that RSpec brought, like contexts, but having used Shoulda for over a year and recently using RSpec on a new project, I can say that I prefer RSpec overall... keep in mind Shoulda''s macros and matchers are available in RSpec too. describe RSpec, "versus TestUnit" do it { should read_fluently } end Yes, a lot of the most visible differences seem to be around the syntax, but the point is that it helps you think more fluidly about what you''re actually trying to do. TestUnit adds mental baggage for up- front testing and the tests have a backward-looking feel, in other words, they read more like they''re verifying what should have happened after it''s done. RSpec tests read more expressively as looking forward to what you would like to achieve, what "should" happen. While the tests are still pure ruby, they read almost like pure English, especially if you take a little extra effort to encapsulate some of the hairy logic into your own custom matchers. The specs can convey their intent much more clearly, instead of only serving as verification of your app''s performance. Your spec suite becomes very readable (to a developer at least) as behaviour documentation, without needing to slow down to work it out too much. That''s not to say you can''t write readable tests in Shoulda or TestUnit, but RSpec helps you frame them better and convey what you mean more clearly. Cheers, Andrew Vit
On Wed, Apr 22, 2009 at 11:35 AM, Brian Takita <brian.takita at gmail.com> wrote:> On Wed, Apr 22, 2009 at 9:34 AM, Brian Takita <brian.takita at gmail.com> wrote: >> On Wed, Apr 22, 2009 at 7:28 AM, Amos King <amos.l.king at gmail.com> wrote: >>> Thanks, David. >>> >>> I do often read the rspec list because of the discussions that you >>> site. ?The community maybe enough for me to make the jump. ?I can''t >>> wait to be able to use RSpec and Test::Unit together as a single >>> cohesive framework. ?I''ll keep working my side project with RSpec and >>> see what ideas I can come up with. ?At work I will continue to use >>> Shoulda, Test::Unit, and Webrat. ?We''ll see what ideas can be ported >>> around. ?I''ll also take a look at the book. >> You can run test/unit & rspec together already. >> >> All you need to do is: >> require "spec/interop/test" >> before your spec definitions. >> >> Here is an example: >> http://gist.github.com/99895 >> >> The shoulda integration did not work, however > What do you think of having ExampleGroup.should create an Example?Aside from the fact that all of the specs for ExampleGroup would start freaking out? :) I''m not sure how to best get around this conflict. "should" means something very specific in rspec, and shoulda gives it a different meaning.>>> >>> I''ve worked on Webrat::Selenium and grid support a bit so let''s see >>> where this can take me. ?Thanks for the ideas from everyone, and >>> you''ve all encouraged me to take a deeper look. >>> >>> Amos(adkron) >>> >>> On Wed, Apr 22, 2009 at 9:08 AM, David Chelimsky <dchelimsky at gmail.com> wrote: >>>> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king at gmail.com> wrote: >>>>> I wasn''t thinking about a gun. ?I was just wondering if there is some >>>>> underlying reason that I''m missing. ?Is there a background structure >>>>> that I''m not grasping? ?Is there a huge piece of functionality that >>>>> I''m missing? ?Is it faster than Test:Unit or Shoulda? >>>> >>>> RSpec is not just about RSpec. It''s about BDD. It''s about encouraging >>>> conversation about testing and looking at it in different ways. It''s >>>> about illuminating the design, specification, collaboration and >>>> documentation aspects of tests, and thinking of them as executable >>>> examples of behaviour. You can do this all without RSpec, but RSpec >>>> aims to help with innovations like: >>>> >>>> * strings as example group names >>>> * strings as example names >>>> * pending examples >>>> * nested groups for flexible organization >>>> * should[_not] + matchers (inspired by hamcrest - a java library) >>>> ?* one matcher supports both positive and negative expectations >>>> * improved failure messages >>>> * flexible/readable/customizable output formats >>>> * built-in mocking framework >>>> * plain text scenarios (now in Cucumber) >>>> >>>> Specifically with Rails: >>>> >>>> * component isolation. ZenTest offered separate test cases for >>>> models/views/helpers/controllers before RSpec, and RSpec extended the >>>> idea by allowing you to run controller examples with no dependency on >>>> views and vice versa. Some folks get nervous with that sort of >>>> isolation, but, generally, folks coming to Ruby from a background in >>>> TDD with Java or .NET are all over it. >>>> >>>> That''s not the full list, but a good overview. You can get some of >>>> these things from other frameworks, but they almost all originated in >>>> RSpec, which has been and will continue to be a center of innovation >>>> in testing in Ruby since its creation in 2005. >>>> >>>> To be clear, it is certainly not the only center of innovation. >>>> Shoulda brought us macros, which are great, and we''ve made it easier >>>> to write your own in RSpec, and now you can use shoulda matchers right >>>> in RSpec. >>>> >>>> Micronaut adds a tagging system that allows you to group examples >>>> together in different ways. This is definitely something we''ll be >>>> adding to RSpec sooner or later. >>>> >>>> Ryan Davis and Eric Hodel continue to bring us game-changing testing >>>> tools like autotest, heckle, flog, and flay. >>>> >>>> RSpec has been around for nearly 4 years now. It has matured quite a >>>> bit, and continues to do so. A twitter poll back in January suggests >>>> that the majority of people doing testing in Ruby are using RSpec: >>>> http://twtpoll.com/r/zhh2fm. Note that this poll pits RSpec against >>>> all other frameworks and it still gets the majority. Polls are polls, >>>> and in a community of over a million Ruby developers, it''s hard (for >>>> me) to believe in the accuracy of a poll that 680ish ppl voted in. But >>>> hey, that''s 360-ish ppl who are at least willing to say they use >>>> rspec, so at least we know that much :) >>>> >>>> The point being that with a lot of users comes a lot of mindshare. And >>>> as RSpec continues to mature and become easier to contribute to, that >>>> mindshare will grow. More and more extension libraries like >>>> rspec_on_rails_on_crack and remarkable will emerge, and RSpec will get >>>> better and better at supporting them. It won''t be long before "rspec >>>> OR test/unit" becomes a false choice, and you''ll be able to seamlessly >>>> use both in a unified suite. This is already largely the case, but it >>>> will get better. >>>> >>>> And let''s not forget http://rubyspec.org/ >>>> >>>> As for which tools to use, you should use the ones that make you happy >>>> and make your job and life easier. If there is something that you like >>>> about shoulda over rspec, then use shoulda. If prefer kickin'' it old >>>> school, stick w/ test/unit or minitest. Regardless of the tools you >>>> use, I''d recommend that you pay attention to RSpec and its community. >>>> There is a lot of action here. >>>> >>>> I''d also recommend that you read The RSpec Book. While the material in >>>> the book is taught through RSpec, and much of the book is very >>>> RSpec-specific, there is quite a bit of exploration of the process of >>>> BDD that can be applied regardless of toolset. Not to mention >>>> introduction to other tools like Cucumber, Webrat and Selenium. >>>> >>>> Thanks for the thought provoking question. I''ve been involved with >>>> RSpec since shortly after its creation in 2005, and I sometimes lose >>>> sight of why I got into it and why I stay with it. This has been a >>>> helpful reminder to me, and I hope you find my ramblings helpful to >>>> you. >>>> >>>> Cheers, >>>> David >>>> >>>>> >>>>> Amos(adkron) >>>>> >>>>> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023 at gmail.com> wrote: >>>>>> I think it''s that RSpec encodes some of the latest BDD into its way of >>>>>> thinking. >>>>>> It has a vocabulary that encourages that, so in a way, yes, it''s all about >>>>>> semantics. >>>>>> Semantics that encourage agile thinking & practice. >>>>>> Also, it allows you to structure your specs (that become your regression >>>>>> tests) in a much more intuitive way than Test::Unit -- I don''t know Shoulda. >>>>>> But if I understood all the pros & cons of two systems & preferred another, >>>>>> I''d use that -- there''s no gun against anyone''s head. ;) >>>>>> ?? Doug. >>>>>> >>>>>> 2009/4/22 Saturn <saturn.sting at gmail.com> >>>>>>> >>>>>>> I am also having same question that i can''t find the reason why i >>>>>>> should go for RSpec instead of Test/Unit. >>>>>>> There is no compelling reason / advantage offered by RSpec except >>>>>>> semantics. >>>>>>> >>>>>>> >>>>>>> Is RSpec all about different syntax??????? >>>>>>> >>>>>>> Thanks in advance for clarifying it??? >>>>>>> _______________________________________________ >>>>>>> rspec-users mailing list >>>>>>> rspec-users at rubyforge.org >>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> rspec-users mailing list >>>>>> rspec-users at rubyforge.org >>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Amos King >>>>> http://dirtyInformation.com >>>>> http://github.com/Adkron >>>>> -- >>>>> Looking for something to do? Visit http://ImThere.com >>>>> _______________________________________________ >>>>> rspec-users mailing list >>>>> rspec-users at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>> >>> >>> >>> >>> -- >>> Amos King >>> http://dirtyInformation.com >>> http://github.com/Adkron >>> -- >>> Looking for something to do? Visit http://ImThere.com >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Wed, Apr 22, 2009 at 9:59 AM, David Chelimsky <dchelimsky at gmail.com> wrote:> On Wed, Apr 22, 2009 at 11:35 AM, Brian Takita <brian.takita at gmail.com> wrote: >> On Wed, Apr 22, 2009 at 9:34 AM, Brian Takita <brian.takita at gmail.com> wrote: >>> On Wed, Apr 22, 2009 at 7:28 AM, Amos King <amos.l.king at gmail.com> wrote: >>>> Thanks, David. >>>> >>>> I do often read the rspec list because of the discussions that you >>>> site. ?The community maybe enough for me to make the jump. ?I can''t >>>> wait to be able to use RSpec and Test::Unit together as a single >>>> cohesive framework. ?I''ll keep working my side project with RSpec and >>>> see what ideas I can come up with. ?At work I will continue to use >>>> Shoulda, Test::Unit, and Webrat. ?We''ll see what ideas can be ported >>>> around. ?I''ll also take a look at the book. >>> You can run test/unit & rspec together already. >>> >>> All you need to do is: >>> require "spec/interop/test" >>> before your spec definitions. >>> >>> Here is an example: >>> http://gist.github.com/99895 >>> >>> The shoulda integration did not work, however >> What do you think of having ExampleGroup.should create an Example? > > Aside from the fact that all of the specs for ExampleGroup would start > freaking out? :)The gist I posted works. All I needed to do it alias :should, :example. I suppose this would have major implications on the rspec suite though, so I can see this not being able to exist with Object#should in rspec core. Others can use this technique, if they like, as long as they do not need to make assertions on an ExampleGroup class instance.> > I''m not sure how to best get around this conflict. "should" means > something very specific in rspec, and shoulda gives it a different > meaning.True. Object#should limits us there. I think the intent and semantics are similar though (in a nested sort of way). describe Foo do describe "#do_something" do should "return true" do foo.do_something.should == true end end end Its like an assertion on the subject of the description. From an object structure point of view, Example != an assertion, but from a semantic point of view, we are making an assertion. Foo#do_something should return true, which means foo.do_something should == true.> >>>> >>>> I''ve worked on Webrat::Selenium and grid support a bit so let''s see >>>> where this can take me. ?Thanks for the ideas from everyone, and >>>> you''ve all encouraged me to take a deeper look. >>>> >>>> Amos(adkron) >>>> >>>> On Wed, Apr 22, 2009 at 9:08 AM, David Chelimsky <dchelimsky at gmail.com> wrote: >>>>> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king at gmail.com> wrote: >>>>>> I wasn''t thinking about a gun. ?I was just wondering if there is some >>>>>> underlying reason that I''m missing. ?Is there a background structure >>>>>> that I''m not grasping? ?Is there a huge piece of functionality that >>>>>> I''m missing? ?Is it faster than Test:Unit or Shoulda? >>>>> >>>>> RSpec is not just about RSpec. It''s about BDD. It''s about encouraging >>>>> conversation about testing and looking at it in different ways. It''s >>>>> about illuminating the design, specification, collaboration and >>>>> documentation aspects of tests, and thinking of them as executable >>>>> examples of behaviour. You can do this all without RSpec, but RSpec >>>>> aims to help with innovations like: >>>>> >>>>> * strings as example group names >>>>> * strings as example names >>>>> * pending examples >>>>> * nested groups for flexible organization >>>>> * should[_not] + matchers (inspired by hamcrest - a java library) >>>>> ?* one matcher supports both positive and negative expectations >>>>> * improved failure messages >>>>> * flexible/readable/customizable output formats >>>>> * built-in mocking framework >>>>> * plain text scenarios (now in Cucumber) >>>>> >>>>> Specifically with Rails: >>>>> >>>>> * component isolation. ZenTest offered separate test cases for >>>>> models/views/helpers/controllers before RSpec, and RSpec extended the >>>>> idea by allowing you to run controller examples with no dependency on >>>>> views and vice versa. Some folks get nervous with that sort of >>>>> isolation, but, generally, folks coming to Ruby from a background in >>>>> TDD with Java or .NET are all over it. >>>>> >>>>> That''s not the full list, but a good overview. You can get some of >>>>> these things from other frameworks, but they almost all originated in >>>>> RSpec, which has been and will continue to be a center of innovation >>>>> in testing in Ruby since its creation in 2005. >>>>> >>>>> To be clear, it is certainly not the only center of innovation. >>>>> Shoulda brought us macros, which are great, and we''ve made it easier >>>>> to write your own in RSpec, and now you can use shoulda matchers right >>>>> in RSpec. >>>>> >>>>> Micronaut adds a tagging system that allows you to group examples >>>>> together in different ways. This is definitely something we''ll be >>>>> adding to RSpec sooner or later. >>>>> >>>>> Ryan Davis and Eric Hodel continue to bring us game-changing testing >>>>> tools like autotest, heckle, flog, and flay. >>>>> >>>>> RSpec has been around for nearly 4 years now. It has matured quite a >>>>> bit, and continues to do so. A twitter poll back in January suggests >>>>> that the majority of people doing testing in Ruby are using RSpec: >>>>> http://twtpoll.com/r/zhh2fm. Note that this poll pits RSpec against >>>>> all other frameworks and it still gets the majority. Polls are polls, >>>>> and in a community of over a million Ruby developers, it''s hard (for >>>>> me) to believe in the accuracy of a poll that 680ish ppl voted in. But >>>>> hey, that''s 360-ish ppl who are at least willing to say they use >>>>> rspec, so at least we know that much :) >>>>> >>>>> The point being that with a lot of users comes a lot of mindshare. And >>>>> as RSpec continues to mature and become easier to contribute to, that >>>>> mindshare will grow. More and more extension libraries like >>>>> rspec_on_rails_on_crack and remarkable will emerge, and RSpec will get >>>>> better and better at supporting them. It won''t be long before "rspec >>>>> OR test/unit" becomes a false choice, and you''ll be able to seamlessly >>>>> use both in a unified suite. This is already largely the case, but it >>>>> will get better. >>>>> >>>>> And let''s not forget http://rubyspec.org/ >>>>> >>>>> As for which tools to use, you should use the ones that make you happy >>>>> and make your job and life easier. If there is something that you like >>>>> about shoulda over rspec, then use shoulda. If prefer kickin'' it old >>>>> school, stick w/ test/unit or minitest. Regardless of the tools you >>>>> use, I''d recommend that you pay attention to RSpec and its community. >>>>> There is a lot of action here. >>>>> >>>>> I''d also recommend that you read The RSpec Book. While the material in >>>>> the book is taught through RSpec, and much of the book is very >>>>> RSpec-specific, there is quite a bit of exploration of the process of >>>>> BDD that can be applied regardless of toolset. Not to mention >>>>> introduction to other tools like Cucumber, Webrat and Selenium. >>>>> >>>>> Thanks for the thought provoking question. I''ve been involved with >>>>> RSpec since shortly after its creation in 2005, and I sometimes lose >>>>> sight of why I got into it and why I stay with it. This has been a >>>>> helpful reminder to me, and I hope you find my ramblings helpful to >>>>> you. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> >>>>>> Amos(adkron) >>>>>> >>>>>> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023 at gmail.com> wrote: >>>>>>> I think it''s that RSpec encodes some of the latest BDD into its way of >>>>>>> thinking. >>>>>>> It has a vocabulary that encourages that, so in a way, yes, it''s all about >>>>>>> semantics. >>>>>>> Semantics that encourage agile thinking & practice. >>>>>>> Also, it allows you to structure your specs (that become your regression >>>>>>> tests) in a much more intuitive way than Test::Unit -- I don''t know Shoulda. >>>>>>> But if I understood all the pros & cons of two systems & preferred another, >>>>>>> I''d use that -- there''s no gun against anyone''s head. ;) >>>>>>> ?? Doug. >>>>>>> >>>>>>> 2009/4/22 Saturn <saturn.sting at gmail.com> >>>>>>>> >>>>>>>> I am also having same question that i can''t find the reason why i >>>>>>>> should go for RSpec instead of Test/Unit. >>>>>>>> There is no compelling reason / advantage offered by RSpec except >>>>>>>> semantics. >>>>>>>> >>>>>>>> >>>>>>>> Is RSpec all about different syntax??????? >>>>>>>> >>>>>>>> Thanks in advance for clarifying it??? >>>>>>>> _______________________________________________ >>>>>>>> rspec-users mailing list >>>>>>>> rspec-users at rubyforge.org >>>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> rspec-users mailing list >>>>>>> rspec-users at rubyforge.org >>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Amos King >>>>>> http://dirtyInformation.com >>>>>> http://github.com/Adkron >>>>>> -- >>>>>> Looking for something to do? Visit http://ImThere.com >>>>>> _______________________________________________ >>>>>> rspec-users mailing list >>>>>> rspec-users at rubyforge.org >>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>> _______________________________________________ >>>>> rspec-users mailing list >>>>> rspec-users at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>> >>>> >>>> >>>> >>>> -- >>>> Amos King >>>> http://dirtyInformation.com >>>> http://github.com/Adkron >>>> -- >>>> Looking for something to do? Visit http://ImThere.com >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Wed, Apr 22, 2009 at 2:05 PM, Brian Takita <brian.takita at gmail.com> wrote:> On Wed, Apr 22, 2009 at 9:59 AM, David Chelimsky <dchelimsky at gmail.com> wrote: >> On Wed, Apr 22, 2009 at 11:35 AM, Brian Takita <brian.takita at gmail.com> wrote: >>> On Wed, Apr 22, 2009 at 9:34 AM, Brian Takita <brian.takita at gmail.com> wrote: >>>> On Wed, Apr 22, 2009 at 7:28 AM, Amos King <amos.l.king at gmail.com> wrote: >>>>> Thanks, David. >>>>> >>>>> I do often read the rspec list because of the discussions that you >>>>> site. ?The community maybe enough for me to make the jump. ?I can''t >>>>> wait to be able to use RSpec and Test::Unit together as a single >>>>> cohesive framework. ?I''ll keep working my side project with RSpec and >>>>> see what ideas I can come up with. ?At work I will continue to use >>>>> Shoulda, Test::Unit, and Webrat. ?We''ll see what ideas can be ported >>>>> around. ?I''ll also take a look at the book. >>>> You can run test/unit & rspec together already. >>>> >>>> All you need to do is: >>>> require "spec/interop/test" >>>> before your spec definitions. >>>> >>>> Here is an example: >>>> http://gist.github.com/99895 >>>> >>>> The shoulda integration did not work, however >>> What do you think of having ExampleGroup.should create an Example? >> >> Aside from the fact that all of the specs for ExampleGroup would start >> freaking out? :) > The gist I posted works. All I needed to do it alias :should, :example. > I suppose this would have major implications on the rspec suite > though, so I can see this not being able to exist with Object#should > in rspec core. > > Others can use this technique, if they like, as long as they do not > need to make assertions on an ExampleGroup class instance. >> >> I''m not sure how to best get around this conflict. "should" means >> something very specific in rspec, and shoulda gives it a different >> meaning. > True. Object#should limits us there. I think the intent and semantics > are similar though (in a nested sort of way). > > describe Foo do > ?describe "#do_something" do > ? ?should "return true" do > ? ? ?foo.do_something.should == true > ? ?end > ?end > end > > Its like an assertion on the subject of the description. From an > object structure point of view, Example != an assertion, but from a > semantic point of view, we are making an assertion. > > Foo#do_something should return true, which means foo.do_something > should == true.Not that that''s its a big deal to me, but this would be useful for somebody trying to use both shoulda + rspec. Maybe there is a better way?>> >>>>> >>>>> I''ve worked on Webrat::Selenium and grid support a bit so let''s see >>>>> where this can take me. ?Thanks for the ideas from everyone, and >>>>> you''ve all encouraged me to take a deeper look. >>>>> >>>>> Amos(adkron) >>>>> >>>>> On Wed, Apr 22, 2009 at 9:08 AM, David Chelimsky <dchelimsky at gmail.com> wrote: >>>>>> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.king at gmail.com> wrote: >>>>>>> I wasn''t thinking about a gun. ?I was just wondering if there is some >>>>>>> underlying reason that I''m missing. ?Is there a background structure >>>>>>> that I''m not grasping? ?Is there a huge piece of functionality that >>>>>>> I''m missing? ?Is it faster than Test:Unit or Shoulda? >>>>>> >>>>>> RSpec is not just about RSpec. It''s about BDD. It''s about encouraging >>>>>> conversation about testing and looking at it in different ways. It''s >>>>>> about illuminating the design, specification, collaboration and >>>>>> documentation aspects of tests, and thinking of them as executable >>>>>> examples of behaviour. You can do this all without RSpec, but RSpec >>>>>> aims to help with innovations like: >>>>>> >>>>>> * strings as example group names >>>>>> * strings as example names >>>>>> * pending examples >>>>>> * nested groups for flexible organization >>>>>> * should[_not] + matchers (inspired by hamcrest - a java library) >>>>>> ?* one matcher supports both positive and negative expectations >>>>>> * improved failure messages >>>>>> * flexible/readable/customizable output formats >>>>>> * built-in mocking framework >>>>>> * plain text scenarios (now in Cucumber) >>>>>> >>>>>> Specifically with Rails: >>>>>> >>>>>> * component isolation. ZenTest offered separate test cases for >>>>>> models/views/helpers/controllers before RSpec, and RSpec extended the >>>>>> idea by allowing you to run controller examples with no dependency on >>>>>> views and vice versa. Some folks get nervous with that sort of >>>>>> isolation, but, generally, folks coming to Ruby from a background in >>>>>> TDD with Java or .NET are all over it. >>>>>> >>>>>> That''s not the full list, but a good overview. You can get some of >>>>>> these things from other frameworks, but they almost all originated in >>>>>> RSpec, which has been and will continue to be a center of innovation >>>>>> in testing in Ruby since its creation in 2005. >>>>>> >>>>>> To be clear, it is certainly not the only center of innovation. >>>>>> Shoulda brought us macros, which are great, and we''ve made it easier >>>>>> to write your own in RSpec, and now you can use shoulda matchers right >>>>>> in RSpec. >>>>>> >>>>>> Micronaut adds a tagging system that allows you to group examples >>>>>> together in different ways. This is definitely something we''ll be >>>>>> adding to RSpec sooner or later. >>>>>> >>>>>> Ryan Davis and Eric Hodel continue to bring us game-changing testing >>>>>> tools like autotest, heckle, flog, and flay. >>>>>> >>>>>> RSpec has been around for nearly 4 years now. It has matured quite a >>>>>> bit, and continues to do so. A twitter poll back in January suggests >>>>>> that the majority of people doing testing in Ruby are using RSpec: >>>>>> http://twtpoll.com/r/zhh2fm. Note that this poll pits RSpec against >>>>>> all other frameworks and it still gets the majority. Polls are polls, >>>>>> and in a community of over a million Ruby developers, it''s hard (for >>>>>> me) to believe in the accuracy of a poll that 680ish ppl voted in. But >>>>>> hey, that''s 360-ish ppl who are at least willing to say they use >>>>>> rspec, so at least we know that much :) >>>>>> >>>>>> The point being that with a lot of users comes a lot of mindshare. And >>>>>> as RSpec continues to mature and become easier to contribute to, that >>>>>> mindshare will grow. More and more extension libraries like >>>>>> rspec_on_rails_on_crack and remarkable will emerge, and RSpec will get >>>>>> better and better at supporting them. It won''t be long before "rspec >>>>>> OR test/unit" becomes a false choice, and you''ll be able to seamlessly >>>>>> use both in a unified suite. This is already largely the case, but it >>>>>> will get better. >>>>>> >>>>>> And let''s not forget http://rubyspec.org/ >>>>>> >>>>>> As for which tools to use, you should use the ones that make you happy >>>>>> and make your job and life easier. If there is something that you like >>>>>> about shoulda over rspec, then use shoulda. If prefer kickin'' it old >>>>>> school, stick w/ test/unit or minitest. Regardless of the tools you >>>>>> use, I''d recommend that you pay attention to RSpec and its community. >>>>>> There is a lot of action here. >>>>>> >>>>>> I''d also recommend that you read The RSpec Book. While the material in >>>>>> the book is taught through RSpec, and much of the book is very >>>>>> RSpec-specific, there is quite a bit of exploration of the process of >>>>>> BDD that can be applied regardless of toolset. Not to mention >>>>>> introduction to other tools like Cucumber, Webrat and Selenium. >>>>>> >>>>>> Thanks for the thought provoking question. I''ve been involved with >>>>>> RSpec since shortly after its creation in 2005, and I sometimes lose >>>>>> sight of why I got into it and why I stay with it. This has been a >>>>>> helpful reminder to me, and I hope you find my ramblings helpful to >>>>>> you. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> >>>>>>> Amos(adkron) >>>>>>> >>>>>>> On Wed, Apr 22, 2009 at 2:01 AM, doug livesey <biot023 at gmail.com> wrote: >>>>>>>> I think it''s that RSpec encodes some of the latest BDD into its way of >>>>>>>> thinking. >>>>>>>> It has a vocabulary that encourages that, so in a way, yes, it''s all about >>>>>>>> semantics. >>>>>>>> Semantics that encourage agile thinking & practice. >>>>>>>> Also, it allows you to structure your specs (that become your regression >>>>>>>> tests) in a much more intuitive way than Test::Unit -- I don''t know Shoulda. >>>>>>>> But if I understood all the pros & cons of two systems & preferred another, >>>>>>>> I''d use that -- there''s no gun against anyone''s head. ;) >>>>>>>> ?? Doug. >>>>>>>> >>>>>>>> 2009/4/22 Saturn <saturn.sting at gmail.com> >>>>>>>>> >>>>>>>>> I am also having same question that i can''t find the reason why i >>>>>>>>> should go for RSpec instead of Test/Unit. >>>>>>>>> There is no compelling reason / advantage offered by RSpec except >>>>>>>>> semantics. >>>>>>>>> >>>>>>>>> >>>>>>>>> Is RSpec all about different syntax??????? >>>>>>>>> >>>>>>>>> Thanks in advance for clarifying it??? >>>>>>>>> _______________________________________________ >>>>>>>>> rspec-users mailing list >>>>>>>>> rspec-users at rubyforge.org >>>>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> rspec-users mailing list >>>>>>>> rspec-users at rubyforge.org >>>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Amos King >>>>>>> http://dirtyInformation.com >>>>>>> http://github.com/Adkron >>>>>>> -- >>>>>>> Looking for something to do? Visit http://ImThere.com >>>>>>> _______________________________________________ >>>>>>> rspec-users mailing list >>>>>>> rspec-users at rubyforge.org >>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>>> _______________________________________________ >>>>>> rspec-users mailing list >>>>>> rspec-users at rubyforge.org >>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Amos King >>>>> http://dirtyInformation.com >>>>> http://github.com/Adkron >>>>> -- >>>>> Looking for something to do? Visit http://ImThere.com >>>>> _______________________________________________ >>>>> rspec-users mailing list >>>>> rspec-users at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> >
On 22 Apr 2009, at 17:52, Andrew Vit wrote:> On Apr 22, 2009, at 4:25 AM, Amos King wrote: > >> I wasn''t thinking about a gun. I was just wondering if there is some >> underlying reason that I''m missing. Is there a background structure >> that I''m not grasping? Is there a huge piece of functionality that >> I''m missing? Is it faster than Test:Unit or Shoulda? >> >> Amos(adkron) > > > Personally, I can''t think of one single huge piece of functionality > that makes RSpec win over TestUnit, but it''s a whole bunch of little > things. > > It can be faster if you make use of mocks/stubs, and separation > between layers: you can test your controllers without having to > render the views. > > Shoulda is good too. It adds some of the features that RSpec > brought, like contexts, but having used Shoulda for over a year and > recently using RSpec on a new project, I can say that I prefer RSpec > overall... keep in mind Shoulda''s macros and matchers are available > in RSpec too. > > describe RSpec, "versus TestUnit" do > it { should read_fluently } > end > > Yes, a lot of the most visible differences seem to be around the > syntax, but the point is that it helps you think more fluidly about > what you''re actually trying to do. TestUnit adds mental baggage for > up-front testing and the tests have a backward-looking feel, in > other words, they read more like they''re verifying what should have > happened after it''s done. RSpec tests read more expressively as > looking forward to what you would like to achieve, what "should" > happen. > > While the tests are still pure ruby, they read almost like pure > English, especially if you take a little extra effort to encapsulate > some of the hairy logic into your own custom matchers. The specs can > convey their intent much more clearly, instead of only serving as > verification of your app''s performance. Your spec suite becomes very > readable (to a developer at least) as behaviour documentation, > without needing to slow down to work it out too much. That''s not to > say you can''t write readable tests in Shoulda or TestUnit, but RSpec > helps you frame them better and convey what you mean more clearly. > > Cheers, > Andrew Vit+1 Andrew. Thanks for summing up the subtle benefits so well. Also, I would add - RSpec has a solid community of extremely helpful, thoughtful and patient people who will guide you though as you learn BDD / TDD. I think that''s a great reflection of the software itself. Matt Wynne http://blog.mattwynne.net http://www.songkick.com
On Wed, Apr 22, 2009 at 7:25 AM, Amos King <amos.l.king at gmail.com> wrote:> I wasn''t thinking about a gun. ?I was just wondering if there is some > underlying reason that I''m missing. ?Is there a background structure > that I''m not grasping? ?Is there a huge piece of functionality that > I''m missing? ?Is it faster than Test:Unit or Shoulda?RSpec appeals to my literary sensibilities. It helps me think about my code in English. As a writer and editor, I find this pleasant. And as a human who''s spoken English longer than Ruby, I find it clarifies my thought and improves my productivity. -- Have Fun, Steve Eley (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org