[rspec-users] Deprecating the mocking framework?

Lance Carlson lancecarlson at gmail.com
Wed Sep 5 11:09:08 EDT 2007


If core was to deprecate the included mocking framework, then why
would they favor mocha over flexmock? I agree we need to have some
agreement as to which one to use, but why the favoritism?

On 9/5/07, Christoph Sturm <christoph.sturm at gmail.com> wrote:
> everybody in this thread is reacting like you are about to remove the
> built in mocking. The idea was to deprecate it, something like
>
> "if you use the build in mocking right now, fine. If you start a new
> project dont use it"
>
> One thing is clear, mocha is much nicer than the integrated mocking,
> nicer syntax, better errormessages, better everything. The rspec
> mocking framework could never compete with mocha or flexmock on its
> own. At the time it was created there were good reasons for that, just
> like there are good reasons to deprecate it now.
>
> No one should be forced to migrate an old project over to new mocks,
> but thats not what we are talking about.
>
> Maybe you should just keep the built in mocking, but recommend mocha
> for new projects, and start using mocha for the samples and generated
> specs.
>
> I recognize that some people like flexmock better, but having one
> recommended framework would make it much easier for people to get
> started. (It will almost feel like mocha was built in :P)
>
> It really feels strange to hear these complains about rspec not having
> everything built in, because the main complain for me and others about
> rspec was always that its too big and has its own mocking that you
> have to use. (This is fixed now and rspec plays very nice with mocha,
> great)
>
> regards
>  christoph
> On 9/3/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > Hi all,
> >
> > I've talked this over w/ a couple of the other committers and we've
> > decided that we will NOT be deprecating the mock framework, at least
> > for the foreseeable future. If/when we do, it will happen with plenty
> > of notice and a clear, painless (as much as is possible) upgrade path.
> >
> > To be clear: this decision is purely pragmatic. Benefits of the
> > existing framework cited in this thread are significant (one-stop
> > shop, generated specs for the rails plugin, etc). And the amount of
> > work it would take to do it right (backwards compatibility, easy
> > upgrade path, support for multiple external frameworks, etc) far
> > exceeds the perceived cost of maintaining the existing framework.
> >
> > Cheers,
> > David
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>
>
> --
> christoph.sturm at gmail.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


More information about the rspec-users mailing list