Duck Typing in my RSpec, Starting a Dice Game, and the Final Day of Boris
This morning I finished off my RSpec copy by adding in the ‘it’ block. I had to do a bit of research on blocks and exceptions, but was able to find what I needed fairly quickly. I wrote my it block using ‘yield’, which basically gives you the outcome of what is in the block. To make this simpler, here is one of the examples I did.
it ‘[] is an array?’ do
expect([]).to be_a ‘Array’
end
In this case, my test is ‘[] is an array?’.
My ‘yield’ is ‘expect([]).to be_a ‘Array’ which returns ‘Test passes!’ due to the methods we created yesterday.
The ‘it’ method takes this yield and determines what to print to the system, in this case, ‘Test ‘[] is an array?’: Test passes!’.
I also installed the colorize gem so I could add colour to my outputs. Passing tests are green, and failing tests are red.
I am very happy that I managed to get this practical done fairly quickly with not much help from Google! Here is the repo with the final code in. I sent it on to a coach to gain feedback, which came back very positive. He suggested a couple more matchers I could add which I have since implemented. He also told me I had used Duck Typing, which I had not heard of before, so here is a quick definition!
“If it walks like a duck, and quacks like a duck, then it must be a duck.”
Ronald Reagan, 1967
Ruby looks at objects based on what they react to rather than what they are. For example if you defined this method:
class DuckTyping
def addon(add, on)
add << on
end
end
and then initialised it with the below:
dt = DuckTyping.new
dt.addon(“Duck “, “Typing”)
It would return “Duck Typing”. However if you did:
dt = DuckTyping.new
dt.addon([1, 2, 3], 4)
It would return [1, 2, 3, 4].
Ruby decides what you want it to be based on the information you give it. You don’t have to specify what you want the outcome to be.
Hence if it looks like a duck (or in this case a string or an array) then it must be a duck (or string/array)! This video was helpful in my understanding of how it worked.
I started another practical this morning, called TDD A Single Object. It asked us to build a dice game based on the TDD principles we had learned so far. I managed to complete this fairly quickly. By starting with the easy tests, watching them fail, and fixing them, it gives you a really clear path on what you need to do. Also writing tests later on makes you realise that maybe some things could work better, helping you refactor. We were given 5 user stories to base our program off of:
- As a board game player, So that I can play a game, I want to be able to roll a dice
- As a board game player, So that I know how many steps I should move, Rolling a dice should give me a number between 1 and 6
- As a dice app developer, So that I give players a good game experience, I want the dice roll to be randomly picked
- As a board game player, So that I can play many types of games, I want to be able to roll any number of dice at the same time
- As a board game player, So that I know what my score was when I rolled several dice, I want to get the result of each dice roll
I started at the top and worked my way down, creating a test, failing it, then writing my code to fix it and pass the test. I admit I forgot to commit to git for the first couple of tests (blasphemy) but after that committed after each Red-Green-Refactor cycle. My program has tests, and passes them, for each of the above criteria. As it went quite quick I also added further functionality to it, the ability to change the number of faces the dice has. I followed the same process, adding the tests first, then writing the code, and refactoring it once it passed. I am happy with the outcome, here is the repo, I have received feedback on this too which was positive, couple of things I could refactor which I have since done, but otherwise good to go! The refactoring I had to do was changing this code:
sum_of_rolls = 0
dice.dice_rolls.each { |dice| sum_of_rolls += dice }
He suggested using inject, so I changed it to this:
sum_of_rolls = dice_rolls.inject(0) { |sum, dice| sum + dice }
Continuing on with Boris Bikes for the final day, as tomorrow we begin the Friday Challenge. Not much more to add, mostly more of the same really!
Although, shout out to whoever wrote Challenge 21 of the Boris Bikes project for a great reference!
Thought I would also share my soundtrack for the day, I might start doing this more often, depends what I am doing that day I think. Personally I hate working in silence no matter what I am doing, so will generally always have at least one headphone in! Here is todays track:
Finally I decided I wanted my train commute to be more productive, my walking time is being used to listen to podcasts, but my train time is currently free. I get the train with my girlfriend, who has been using Duolingo to brush up on her Spanish which she learned at school, so I decided to download it and try to learn Spanish too! I am not sure how good an idea that is considering I am already trying to learn multiple coding languages at Makers, but we will see how long I can keep this up!
Josh's Blog 