---
title: "Testing Your Code’s Text"
date: 2011-08-31T00:00:00+00:00
draft: false
canonical_url: https://www.viget.com/articles/testing-your-codes-text/
---

The "Ubiquitous Automation" chapter of [*The Pragmatic
Programmer*](https://books.google.com/books?id=5wBQEp6ruIAC&lpg=PA254&vq=ubiquitous%20automation&pg=PA230#v=onepage&q&f=false)
opens with the following quote:

> Civilization advances by extending the number of important operations
> we can perform without thinking.
>
> --Alfred North Whitehead

As a responsible and accomplished developer, when you encounter a bug in
your application, what's the first thing you do? Write a failing test
case, of course, and only once that's done do you focus on fixing the
problem. But what about when the bug is not related to the *behavior* of
your application, but rather to its configuration, display, or some
other element outside the purview of normal testing practices? I contend
that you can and should still write a failing test.

**Scenario:** In the process of merging a topic branch into master, you
encounter a conflict in one of your ERB files. You fix the conflict and
commit the resolution, run the test suite, and then deploy your changes
to production. An hour later, you receive an urgent email from your
client wondering what happened to the footer of their site. As it turns
out, there were *two* conflicts in the file, and you only fixed the
first, committing the conflict artifacts of the second into the repo.

Your gut instinct is to zip off a quick fix, write a self-deprecating
commit message, and act like the whole thing never happened. But
consider writing a rake task like this:

```ruby
namespace :preflight do
  task :git_conflict do
    paths = `grep -lir '<<<\|>>>' app lib config`.split(/\n/)

    if paths.any?
      puts "ERROR: Found git conflict artifacts in the following files\n\n"
      paths.each {|path| puts " - #{path}" }
      exit 1
    end
  end
end 
```

This task greps through your `app`, `lib`, and `config` directories
looking for occurrences of `<<<` or `>>>` and, if it finds any, prints a
list of the offending files and exits with an error. Hook this into the
rake task run by your continuous integration server and never worry
about accidentally deploying errant git artifacts again:

```ruby
namespace :preflight do
  task :default do
    Rake::Task['cover:ensure'].invoke
    Rake::Task['preflight:all'].invoke
  end

  task :all do
    Rake::Task['preflight:git_conflict'].invoke
  end

  task :git_conflict do
    paths = `grep -lir '<<<\|>>>' app lib config`.split(/\n/)
    
    if paths.any?
      puts "ERROR: Found git conflict artifacts in the following files\n\n"
      paths.each {|path| puts " - #{path}" }
      exit 1
    end
  end
end

Rake::Task['cruise'].clear

task :cruise => 'preflight:default' 
```

We've used this technique to keep our deployment configuration in order,
to ensure that we're maintaining best practices, and to keep our
applications in shape as they grow and team members change. Think of it
as documentation taken to the next level -- text to explain the best
practice, code to enforce it. Assuming you're diligent about running
your tests, every one of these tasks you write is a problem that will
never make it to production.
