This is why mocking and stubbing sucks:
http://cardarella.blogspot.com/2008/12/case-against-mocking-and-stubbing.html

This is why mocking and stubbing is awesome:
http://blog.davidchelimsky.net/2008/12/11/a-case-against-a-case-against-mocking-and-stubbing

And, this is what the godfather says about this:
http://martinfowler.com/articles/mocksArentStubs.html

Who else is confused? I think the TDD/BDD community needs to start explaining themselves more regarding the principles of testing. We need a "pattern" for TDD/BDD testing for Ruby and Rails (Merb) projects.

I have had many conversations/debates regarding this very issue. And, every time I read one of these articles, I go from one side to the other.

So far, here are my conclusions regarding testing:

* TDD/BDD is hard.
* TDD/BDD is necessary.
* 100% coverage is unrealistic.
* Doing "red, green, refactor" all the time almost never happens in the real world.
* Someone needs to write an up-to-date and definitive book regarding this subject matter, and end the debate.

Great Enumerable#inject tutorial and introduction: http://blog.jayfields.com/2008/03/ruby-inject.html

Thinking out of the box with Enumerable#inject: http://advent2008.hackruby.com/past/2008/12/11/thinking_out_of_the_box_with_enumerableinject/

Posted by the guys at RailsEnvy.com for a talk they gave at Ruby Hoedown. http://www.railsenvy.com/assets/2008/8/8/RubyInnovation.pdf

Some interesting things that I did not know about.

I often get asked and see forum/blog post asking this question (or some variation of it):

"What do I need in order to start Ruby on Rails development?"

The following may not apply to all. But, face it. Admit it. There can be only one way. So, just follow this simple step to more joy and bliss. Here is the step to take. Yes, there is only one step.

Grow some balls

"But, but, but . . . those are my budz, my free time, my weekends . . . wha, wha, whahaaa".

So, tell me about your balls growthage

"But, that's easy for you to say. I am in (insert some worthless excuse here) . . . blah, blah, blabbity, blah, blah . . ."

What's the technology that you left behind?

What to read

• Getting Real


• The Ten Faces or Innovation


• Beyond Java


• From Java to Ruby


• Extreme Programming


• Rails Way


• Ruby Way


• Web Standards Solutions

• RailsCasts


• Rails Envy

It's not code, it's passion

Without getting into real detail, I need this behavior because of a legacy database (Actually, it is not all that "legacy". It is more "enterprise-esque".).

Anyway . . .

Question: Can an ActiveRecord object invoke an instance method, then, while executing that method, destroy itself?

Code example:

@some_object.some_method

Class SomeObject < ActiveRecord::Base
  def some_method
    ...Some really awesome stuff happens here...
    self.destroy
  end
end

@some_object.some_method

Class SomeObject < ActiveRecord::Base
  def some_method
    ...Some really awesome stuff happens here...
    SomeObject.find(self).destroy
  end
end

This is pretty sweet.

Rails strictly adheres to the MVC model . . . which is good. Where Rails falls a little bit short is when a view needs to manipulate multiple models. The out of the box Rails behavior is one model to one controller to one view.

But, in practice, you often have views that manipulate multiple models. Thankfully, because Rails is flexible, you can accomplish this in a number of ways. However, it often leads to inconsistent code structure, and fat controllers, or nearly untestable code.

What we needed was a “pattern”. I had heard about the presenter pattern last year at RailsEdge in Chicago. At the time, it was just a concept. I didn’t really get it.

Looking at this post (ActivePresenter), I get it now. And, its implementation is pure elegance. I can't wait to try it out.