Dynamic Types, Real tests!
After developing, using, and babysitting a production Rails application for a few months now, I have come across this not-so-juicy tidbit: if you use a dynamically typed language, you better use some 'real' tests. This may seem obvious, but I think that this is one of the reasons that the Rails community has put so much into Test Driven Development. When you're writing Java, you (and all the developers on your projects), have a bit of testing baked in to every expression of code; the first gauntlet of tests your code passes is the compilation.
Writing Ruby, however, you can monkey-patch and duck-punch to your hearts content. And maybe even you have a ton of unit tests for the business logic, regression tests and integration tests. You need some detailed unit tests to test any core features you are extending. Just because you can write something in a few expressive lines of code doesn't mean there can't be dozens of edge-cases. In a fast-paced work environment, my teams tend to rely on a small set of general tests and a solid QA pass, rather than marching in the face of the 80/20 rule and trying to test each little bit. Or at least that is how we did it. Now we're gonna have unit tests for core extensions, no matter how trivial.
Because you might try to execute the "foo" method on the "bar" object, which is totally loco, and something won't work, or it will error, and why would you ever try to run bar.foo? Fine. Sometimes, though, if you are extending functionality around generic or common methods ("each", "flatten", "to_s", "nil?", "blank?") you can find some edge-cases that still work and produce passable output, until you start digging in.