Buzzwords like BDD, TDD, ATDD, RDD, and DDD may have convinced you that writing great, maintainable code is just a matter of following a few simple instructions. All you need to do, you've been told, is write good unit tests, and make sure you have a good CI suite to call you out when your tests fail.

Following the zealotry of the day will leave you with brittle and vulnerable tests after every refactor. You will write coupled code and expose far too much implementation detail to consumers of your code. This is exactly what happened with Merb 0.5, which was almost feature-for-feature compatible with Merb 1.0, but with a mishmash public API that made it very difficult to detect the breaking changes we introduced.

Beginning with Merb 0.9, we took a radically different approach, focusing almost entirely on the public interfaces we were exposing. We made sure that our tests covered those interfaces, not merely the individual methods that were being run. Along the way, we learned lessons about testing, writing code to be used by others, loose coupling, public interfaces, and a whole lot more.

Join me as we examine some of those lessons, using Merb as a lens. We'll be challenging many orthodoxies of today's Ruby programmers, so if you fear change, stay away. On the other hand, if you're looking for some new ways to think about writing complex systems, testing them, and making your tests resilient to even the most invasive refactoring, join me. Let's step through the looking glass together.

About Yehuda Katz
In addition to being the co-author of jQuery In Action, a contributor to Ruby in Practice and co-author of the upcoming Merb in Action, Yehuda is a core contributor to DataMapper and jQuery. Before coming to Engine Yard, he was the lead developer on a large construction management app written in Ruby on Rails. Yehuda is a Merb core developer, contributes to Rubinius, and is taking a lead role in the development of our Engine Yard's new Control Panel.