gistfile1

Testable Abstractions in Rails
=============================

In Java or C#, it is common to build abstractions around external
dependencies like Logging or Caching libraries.

The advantages of such abstractions are twofold:

1) They can allow the caller to hide the methods/usage patterns that aren't
   relevant to their application.
2) They can provide a testable abstraction layer if the library does not use
   interfaces or a requires too much setup to do testing.

Examples:
1) Log4net contains multiple overloads of log, most callers end up using 3
   or less in their actual applications.
2) Database drivers/adapters end up with lots of boiler plate code to
   initialize, utilize, and close a connection, most applications wrap
   this logic

In rails, it appears to be that most developers will pull in a gem and
just cargo-cult the gem's built in API or usage patterns. Over time,
this can lead to a lot of confusion for newbies and increase the
complexity of the codebase simply because of the lack of consistency
across gems. Examples I've seen are the following:

1) File attachment gems (CarrierWave, Paperclip)
2) Tagging gems (Acts As Taggable On)
3) Search/filter gems (Meta-Where, Meta-Search, Texticle)

The other big issue is that often these gems go out of date and need
to be replaced due to a Rails framework upgrade or the author(s) no
longer maintaining it.

It would be a great to see a post addressing some techniques in
minimizing this pain for Rails devs by helping them build up the
appropriate levels of abstraction to assist in long term maintenance.