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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > -- > [EMAIL PROTECTED] > _______________________________________________ > 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
