A Live Developer Journal

Writing first failing, failing and failing test in Ruby using RSpec

This week I have had horribly low confidence in my coding ability. I work at a start-up alongside two world-class developers. I'm still at the start of my journey when it comes to programming the way they can. It frustrates me that I am not able to come up with clean solutions the way they can. My negative self-talk on this has gotten a bit out of hand, so I'm going to stop thinking about how much I can't do, and start trying out the things that scare me.

This entry is going to be rough documentation of my attempt at breaking down a problem into tiny pieces and solving it using a test-driven development approach.

For this entry, all I'm going to do is write a first failing test that I'm going to throw away at the end. This is to refresh my memory of how Ruby testing works - have played with it before but am by no means an expert.

Instead of writing down what I did after I did it, I'm going to write down what I'm going to do before I did it.

Setting up empty project linked up to version control


  describe 'First test' do
    it "should fail and pass as expected" do
      expect(FirstTest.toConfirmTestsWork()).to eql('Yep we can write a test that passes')
    end
  end


describe "First test should" do
  it "fail and pass as expected" do
    expect(FirstTest.toPass()).to eql('Yep, we can write a test that passes')
  end
end

Back to writing what I'm going to do before I do it.


RSpec.describe "First test should" do
  it "fail and pass as expected" do
    expect(FirstTest.toPass()).to eql('Yep, we can write a test that passes')
  end
end


class FirstTest
end


class FirstTest
  def toPass
  end
end

Review

While this whole post highlights all the mistakes I made, it also captures a few really useful things to know about RSpec, Ruby and error messages. I also implemented some advice from TDD articles and colleages without really being concious of it until reading back over this. Will recap those here:

I feel a little embarrassed about sharing this one, because I literally documented everything that went wrong, as it went wrong. That happened a lot. But the probability of me making these same mistakes will be reduced for the next post I write.

I was thinking about automating my tests, but leaving it for now. The trains program I'm writing is a learning exercise. Will be pairing on it because while I can make it happen myself, I need someone who knows how to write well-principled code to help change the way I think about solving problems. So this experiment is messy, raw, ugly - to help make the benifits of the pairing sessions even more obvious.