Should a guardfile be part of your repo?

So you have a Ruby project and you practice TDD. Now to not make it too hard on yourself to run your test suite every single step of the way your using guard to speed up your process. Good for you and it should make testing as fun as it could be.

Now as I’ve been moving from project to project I’ve seen different practices when it comes to using guard. Some good, some bad but all beneficial for different reasons. What I did find if most projects is that the Guardfile is shared by putting it in the repository of the project. Now I’m wondering, is that a good practice?



So, why would we?

The practice of making the Guardfile part of our repository is that we see it as part of our test suite. We want to share tips and tricks between developers and we want to have an easy way to get started. By sharing the Guardfile we also ensure that testing is done with certain standards.

So, why would we not!

There are three factors that are mentioned as pro’s and one assumption that is made. Let’s have a closer look at sharing of practices, ease of use, maintaining standards and the assumption that it is part of our test suite.

Test suite relation

Guard is an interesting gem as it’s part of the testing practice without really being part of the test suite. You can perfectly run and maintain the tests and their integrity without using guard and it does not add anything to the results of the test. In that way it is a tool that you can use to help you test, like git is to help you do version management and tmux helps you to manage different console windows. It is almost like submitting or git-ignoring IDE project files in your repository. But I do not see it being part of your testing suite as it’s just a tool.

Sharing tips and tricks

Developers love sharing code. Putting .dotfiles on Github, sharing code snippets or sharing solutions to problems on stack overflow. They always find ways to share tricks tips and tricks so why would you want to do it in a repository for something else. The Guardfile in that sense if very much like the .dotfiles that we share on Github. They are our personal preferences and configurations. I think a repository should be used for sharing product code, not tips and tricks.

Ease of use

Having a Guardfile already in your repo can be useful because you can do a git clone, do an initial bundle command and type guard to get going. Adding one step can get you to almost the same level. The command ‘guard init’ will create a Guardfile for you in seconds, and very likely it will do it about the same as the shared version.

Maintaining standards

It is true that a Guardfile can help maintain a certain level of standard as all the users are confronted with the same practices. I’m however not sure that guard is the way to enforce these practices. Developers can choose not to use guard or they could not write the tests in general. And in my experience dictating choice of tool to developers is not very conductive of their productivity anyways.

What are the advantages

There are some extra advantages that come with treating Guardfiles the same as any other tool files like IDE project files.

Team versus personal preferences

A lot of the time you will work with developers that have slightly different practices due to their different specialties. Some people love livereload when they are working on an app. I personally hate it as I do a lot of tweaking in my browser and when I then transplant it back into the code it disappears from the browser. The same goes for running a Rails server from guard or restarting it manually. By having your own Guardfile your in charge of what you use and what you don’t use.

Development environment agnostic

Like many are doing now moving away from just using .rvmrc file and are using the more agnostic .ruby-version and .ruby-gemset so that the developers are not stuck with using RVM as the way of managing their Rubies. You can do the same with guard. the notifier for instance can be set to your personal preference. You can use growl, tmux, gntp or libnotify. Whatever your development environment supports.


Disadvantages: You will have to find another way to share tips and tricks about your Guardfiles. You will also have to setup your own Guardfile.

Advantages: You will become more development environment agnostic. Also you can have developers use their own preferences with their own workflow to be most efficient.

My vote: No! I would prefer having an agnostic environment and a workflow that is catered to me than the convenience of a predefined guard setup.

, , , , ,

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: