I recently started writing user stories and acceptance tests. My first drafts of acceptance tests were bad. There was little clarity around what I would actually be delivering to the client and a lot of ambiguity.

It’s important to make sure you and the client, whether that person is part of you own company or a company that you are consulting for, are on the same page. The last thing you would want would be to do a week’s worth of work and then have the client disagree with the deliverables.

The Given/When/Then strategy for writing user stories and acceptance tests made it significantly easier for me to think through all the features needed and estimate how long it would take to complete the features. Continue reading

How to Test Ruby IO

Receiving input from a user, doing something with that input, and then displaying some output is core to software development after QA services that help you check your software. This input and output is reffered to as IO.

In TDD, we should test the behavior of all the code we write, but testing IO can be challenging because we don’t want to be prompted for input or have miscellaneous text printed in the terminal while running our tests. I’m going to walk through a scenario where we have a UI class (i.e., user interface) in Ruby that handles all of the IO and explain how to test it. We’re also going to look at the IO class and its STDIN and STDOUT constants. Continue reading

Single Responsibility Principle

There’s a group of guidelines and principles to help us write clean code in object-oriented programming–commonly called SOLID–which was introduced by Robert Martin (aka Uncle Bob).

The five principles of SOLID are:

  1. Single Responsibility Principle
  2. Open-Closed Principle
  3. Liskov Substitution Principle
  4. Interface Segregation Principle
  5. Dependency Inversion Principle

Right now I’m going to explain the Single Responsibility Principle with a real world example. Continue reading