Tag Archives: rails

Optimizing for stable tools that don’t create perpetual work

Time is an incredibly important asset.

I come from a Ruby on Rails background. The progress of Rails updates & JS frameworks has been amazing & constant. Each new Rails patch brings with it some work to stay current. It’s not Rails’s fault since there are always new features or security issues that arise. Having a well maintained framework, such as Rails, is a huge boon for the community.

With any programmer tool, you generally want to be on the current stable release (for a variety of reasons including security & bug fixes). The issue is that upgrading to the latest stable version creates a never ending stream of (hopefully small) work.

Even if you went without a framework (Rails, Django, etc.), your server is running on a suite of tools. You’ll need to keep your OS (even LTS) and most likely nginx up to date.

Perhaps you want to outsource server maintenance, so you’re using Heroku. You’ll have to keep your configs compliant with the Heroku deployment framework & best practices.

What I’m getting at is that there are so many incredible tools available to developers today. Oftentimes, these tools are free and constantly get better & faster over time.

I’m wondering if there is, or if it would be possible to create developer tools that are optimized for API stability. No more figuring how to do things the framework-way every several months. Setup once, use forever. When you’re able to minimize the present value amount of time spent maintaining a tool, you’re freeing your future self to work on higher value tasks.

Misc Rails Integration Test Tips

I attended an Automated Testing meetup yesterday. In my experience, integration tests turn your speedy test suite into a slowpoke. Here are some different tips and gems to consider using in your tests:

  • rack_session_access Gem
    Instead of making a user log in with capybara, why not set the user_id in the session. This gem sounds amazing.
  • fuubar Gem
    Another way to format your test results. Perhaps you’d like to use a progress slider.
  • rspec-retry Gem
    If a test does not pass on the first try, you can run it again until it passes. This feels like a code smell. In the meetup, the speaker mentioned that they were running their tests against live web requests (instead of pre-recorded requests).
  • Page Objects
    Capybara syntax seems procedural since you are telling it to visit a path and click on things. With page objects, you can have DRY code that abstracts away all the step by step page interactions with something like ProjectPageObject.create
  • View Tests
    Instead of doing full blown integration (feature) testing that uses a browser, you can try view tests that assert things are found on your page.

Hopefully you can use some of these tips to improve your test suite.