It was about a year ago that we first announced Raygun, our Rails applications generator. Since then, many apps have been zapped into existence, both internally at Carbon Five and in the wild. Raygun evolved over the year; it does more of some things and less of others. Let’s see what Raygun does and what …
The technique of composition over inheritience is more than simply encapsulating objects into larger entities; its really about defining models as being made up of resuable behaviors. It makes sense then in Behavaior Driven Design we apply the technique not just when writing the implementations of our models but also when creating the specifications themselves. …
Acceptance tests are a great tool for guiding [outside in testing] and defining application behavior. Unfortunately they are also notoriously slow and often brittle. At Carbon Five we usually use Capybara to drive our acceptance tests (either directly in RSpec feature specs or within Cucumber steps) so let’s explore some ways we might accidentally write …
We start new Rails projects all the time, for client, side and internal projects. Each time we do the dance to get things just the way we like them. You probably have a similar process: switch the view library, set the database, use rspec, tweak this and that, etc. Even when you do it all …
Integrating with an external API is almost a guarantee in any modern web app. To effectively test such integration, you need to stub it out. A good stub should be easy to create and consistently up-to-date with actual, current API responses. In this post, we’ll outline a testing strategy using stubs for an external API.
The RSpec Book defines outside-in Rails development as starting with views and working your way in toward the models. By developing from the outside in, you are always taking a client perspective at each layer of the application. The end result is an absolute minimum implementation, consisting of simple, expressive interfaces. Outside-in development doesn’t require …
On one of our rails projects I am creating an api to allow mobile clients to access a web service. I need to provide documentation of this API to the developers of several different clients during its development. Normally I would prefer to let my API tests act as documentation of the expected API behavior …
Overview TDD is fun, right? Rails enthusiasts and agile evangelists alike agree. Waiting for your tests to run, however, makes for a frustrating experience. When the time between test iterations is magnified by bloated tests it can be hard to maintain a purist’s test-driven approach. After looking into autotest, parallel testing, and in-memory databases, I …