On Wed, Apr 22, 2009 at 9:59 AM, David Chelimsky <dchelim...@gmail.com> wrote:
> On Wed, Apr 22, 2009 at 11:35 AM, Brian Takita <brian.tak...@gmail.com> wrote:
>> On Wed, Apr 22, 2009 at 9:34 AM, Brian Takita <brian.tak...@gmail.com> wrote:
>>> On Wed, Apr 22, 2009 at 7:28 AM, Amos King <amos.l.k...@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 <dchelim...@gmail.com>
>>>> wrote:
>>>>> On Wed, Apr 22, 2009 at 6:25 AM, Amos King <amos.l.k...@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 <biot...@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.st...@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@rubyforge.org
>>>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> rspec-users mailing list
>>>>>>> rspec-users@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@rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>> _______________________________________________
>>>>> rspec-users mailing list
>>>>> rspec-users@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@rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
