Skip to main content

Benjamin Oakes

Photo of Ben Oakes

Hi, I'm Ben Oakes and this is my geek blog. Currently, I'm a Ruby/JavaScript Developer at Liaison. Previously, I was a Developer at Continuity and Hedgeye, a Research Assistant in the Early Social Cognition Lab at Yale University and a student at the University of Iowa. I also organize, ICRuby, OpenHack Iowa City, and previously organized NewHaven.rb. I have an amazing wife named Danielle Oakes.

Giving Up on TDD

by Ben

Not just the tests. You have to DESIGN period. No matter what you are writing; whether a unit test, or an acceptance test, or production code, or a mock, or a stub, you have to DESIGN.

Source: Clean Coder Blog

Jay Fields’ Thoughts: Testing: One assertion per test

by Ben

Limiting your tests to using one assertion is a controversial topic. I originally stumbled upon the idea on Dave Astels’ blog. I liked the style of development that Dave described and decided to give it a try, that was over 2 years ago. Since then I’ve worked on teams ranging from 4 developers to 16, codebases in Ruby and C#, and project timelines ranging from 3 months to 8. I think it’s fair to say I’ve given the concept plenty of chances to fall down. But, regardless of the variables, the guideline has always remained valuable.

For me, the main motivator for using one assertion per test is the resulting maintainability of the test. Tests that focus on one behavior of the system are almost always easier to write and to comprehend at a later date.

Source: Jay Fields’ Thoughts: Testing: One assertion per test

6 Ways to Remove Pain From Feature Testing in Ruby on Rails

by Ben

6 Ways to Remove Pain From Feature Testing in Ruby on Rails.

From the article:

Writing feature tests in Ruby on Rails used to be the most painful part of my development work flow. Now I kind of like it.

The Rails Testing Pyramid

by Ben

The Rails Testing Pyramid.

We’ve fallen into doing most of what this blog post recommends, which was a nice surprise. Personally, I’m not the best at “throwaway tests”, but that’s something I’ll be keeping in mind.

Gist: test behavior and edge cases at the unit level (the most tests, base of pyramid), test core integration and “non-unit” functionality at the service level (fewer tests, middle of pyramid), and test only critical UI flows at the acceptance level (fewest tests, top of pyramid).