Archive for September, 2014

3 RSpec Book chapter-5 “output” solutions

Monday, September 15th, 2014

I’m doing some volunteer work for an organization as a Ruby Programmer and as such, I’m having to come up to speed on RSpec in a hurry.


Well today I got stuck in the middle of chapter 5.  I’m talking “thrashing all over the internet” kind of stuck here.  Sadly my google-foo was failing me until just a moment ago (about 1am on a Saturday night, Sunday morning.)


Thankfully Carmen Berros not only had my exact problem, she took the time to write up and link to her friends suggestion.


If you are looking to understand what all the big deal is with BDD, even if you are not a ruby programmer, “The RSpec book” (affiliate link) is wonderful, and well worth your time



Another problem I ended up having with this chapter were my RSpec tests passing, but my Cucumber tests failing.

That solution turned out to be to change the name of “output” to “terminal_output” in



Lastly, if you haven’t found the solution to the dreaded “should is depreciated” messages, the solution is hinted at here  (this also goes in features/step_definitions/codebreaker_steps.rb)

I’ve included the two lines that I tested

#output.should_receive(:puts).with(‘Welcome to Codebreaker!’)
expect(output).to receive(:puts).with(‘Welcome to Codebreaker!’)

#output.should_receive(:puts).with(‘Enter guess:’)
expect(output).to receive(:puts).with(‘Enter guess:’)


If this helps you in your RSpec journey, think about leaving a comment to let us know why you’re taking the time to learn RSpec.

Mobile Apps & TDD – It doesn’t have to be that hard.

Tuesday, September 2nd, 2014
Was having a conversation a couple of days ago and the subject of TDD with Mobile Development came up.
The bottom line was that, “most companies that are doing mobile apps could use TDD training.”

What happens is, they hear that “mobile is different” and then don’t write their code in a way that is testable.

This leaves them with an app who’s internal logic can only be validated by white box testing on as many different devices and operating systems as possible.

There are even people making the case that TDD doesn’t work for mobile because TDD only tests your code’s internal logic.

That’s a punch line.  Testing your code’s internal logic is what Test Driven Design  is intended to provide.

For those of you who would like to dig deeper on why TDD in the mobile space, read Robert van Loghem’s article “Why TDD + Continuous Testing is Imperative for Mobile Apps”

Robert references an old Object Mentor article that is no longer available except through the “Wayback Machine.”  You can read “Continuous Testing Explained” here