On Tue, Nov 4, 2008 at 6:39 AM, Tom Stuart <[EMAIL PROTECTED]> wrote: > Hi, >
> Any responses to > http://blog.caboo.se/articles/2008/11/4/we-ve-stopped-using-rspec ? How much > of this is due to legitimate bugs/problems versus unfortunate circumstances? > Feels kind of worrying that they haven't been able to make it work for them. <sarcasm>Oh my, the end of world is near!</sarcasm> The gem dependency is a real problem. Coming from the Windows world where we have to deal with DLL inter-dependency and loading issues, we are quite familiar with these issues (not having the gem/library in the server, loading it break other tasks, etc). What is missing from the config.gem concept is the possibility to specify the context in which these gems get loaded. Why you need RSpec in production? why is that being loaded? Even if you define rspec and rspec gems as your application dependencies, they shouldn't be forced on *every* environment, which is the root of these issues. Other issues like specs not being executed I can agree on that, I found sometimes some before(:each) do not run, and sometimes they do... when tried to track that down, the problem disappeared. >From that I have plenty of stories, but any application or tool of the size of RSpec have these issues. Take for example Test::Unit... is a 3K lines of code beast. mini-unit from Ryan Davis is around 600 lines and do the same stuff, much more faster, and besides the war at ruby-core about it, I don't hear anyone ranting about the beast it is. So: the defacto vs. the newcomer. The full of classes and unpronounceable methods names vs. the descriptive ones. Pick your framework. -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
