Will the real Error please stand up? Day 3 of Makers

Chris C
3 min readFeb 3, 2021

Happy hump day! It was our first day of independent learning in the morning so we had free rein of what to do until 2pm. All that freedom, gosh — I felt like I had all the time in the world. Actually no, we had a pretty specific action plan for the morning in order to achieve the goals we have set for ourselves today, and for the rest of the week.

I can TDD(Test-Driven Development) anything

I can program fluently

I can debug anything

Most of the challenges for our Boris Bikes project yesterday felt manageable, except for the Rspec element which my partner and I wasn’t quite comfortable with. The pre-course covered the basics so we were thrown off when it asked for predicate matchers — what? Actually it’s not that complicated. You have predicate methods when the method returns true or false. So, in order to match rspec statements with them and make them read a little bit more like your usual English sentence, you can add ‘be_’ to the method, and remove ‘?’. Rspec then automatically identifies the method through the matcher’s syntax.

3.should_not be_even         # calls 3.even?[].should be_empty           # calls [].empty?

Hannah from my peer group also recommended a Udemy Rspec course that was suggested by someone in the previous cohort. All that word of mouth surely must be true! So I will probably take a look at that when I feel like watching some videos. For the rest of the morning, I just went through most of the links that were posted by Eoin, the course material on Github and some more Rspec documentation, with the hope that would prepare me for Boris Bikes round two in the afternoon.

My pairing partner for the afternoon was fellow American Gods lover, Max! And his adorable puppy, aww… We had heard the furthest anyone in the previous cohort got to was step 16, so we were keen to get as far as we can today, dare we way beat the record by the end of the week? Ahem please. This is not a competition.

One might say we didn’t have a good start when we had Github troubles through fiddling around with git pushing and pulling and pushing our repos. Don’t worry, we got the hang of git collab-ing by the end of the day. When we actually got around to working on the project, it was pretty fun. There were more tasks that we were less familiar with so we spent some time researching about it (raising exceptions in code and including them in our tests, and the Single Responsibility Principle) then getting as far as step 16, hurray!

I found errors quite enjoyable — and obviously it is important to raise appropriate error messages for the user when something goes wrong. In the meanwhile, what is the Single Responsibility Principle? Robert C. Martin described it as:

A class should have one, and only one, reason to change.

Whilst a rather vague principle, in essence it means every class, or even object should do exactly one thing. When they have too many functions and therefore ‘reasons to change’, it becomes problematic when you need to change the code when its requirements change.

With all that feature and unit testing, I feel pretty confident about making some progress in the goals above. I will probably do a couple more exercises to practice TDD, so that I can get used to it instead of being tempted to just speed-code right away.

Meanwhile, excuse me as I go sleep off my Chinese takeaway food coma…

--

--