TDD & More
Date: 3rd October 2022, 3:25 pm
It is pretty incredible if I look back through my first 10 days at Makers and realise what I have learned. In my last blog, I had mentioned just how positive day one was which is a great start to any week. I also felt that I may know just enough about Ruby and Object Orientated Programming to survive the first week. I wasn’t entirely wrong, but there were various curveballs thrown, and Test Driven Development (TTD) was the main one.
It is an absolute pleasure to code a small program and see the final result. For the most part, this is why I am changing careers. But when I was initially shown the TTD process, it seemed quite tedious and long-winded. I didn’t understand the syntax, considering I had never seen it before and I felt it may have been unnecessary. The process in short, as I understood it, is writing out a test basically telling the program what you want it to do and then running that test knowing it will fail because you haven’t written any code. Then celebrate the fact that you got errors; errors are good. I can grasp the idea that errors are good because I can relate it to my previous experience of near-miss incidents being good.
Jump ahead one week, after extensive research and practice, I now realise the importance and completely agree with the purpose and value of the TTD process. Once the test is written, you can fix every error that is raised with the minimum amount of code, one error at a time. The result will be no errors of course. Following this TTD process would also mean that your code always worked at least 1 minute ago. The errors that are raised during the process are also very informative providing you with the type of error and where the error lies to even the exact line number in the code. Sometimes, the error messages may even provide a recommendation on a fix to resolve the error. This information is very important and will reduce or even eliminate any potential bugs in the program.
As much fun as "debugging" is, it can be very time-consuming. Reading through hundreds of lines of code, scanning each line in detail, looking for the tiniest mistake that may be causing your code to fail can be very frustrating. Eventually, you may find a method, section or line of the code that is bugged. Using the "p" statement to return "before and "after" to find the exact line where the bug may lie is a very useful and effective debugging process. If there is a bug, it is very unlikely that your "after" statement will not print. Once you have identified the bug, you can then resolve it until both "before and "after" print to the console. I am happy that I have been shown this method to find bugs in the code. However, if you follow the TTD process, debugging will not be necessary, or it may be minimal, as the likelihood of there being a bug is considerably low.
We have completed the challenges given to us using the TTD method, including Boris bikes, Airport, Oyster card and Takeaway challenges which proved to be quite difficult.
The next challenge is getting a better understanding of splitting classes and making sure the tests still pass. Along with that comes stubbing and mocking. With all the questions I have, one duck may not be enough, so got Waddles a little friend. Meet Michael Quackson. Hope he can provide some answers.
I would also like to give a shoutout to #100DaysOfCode. It is really a great community to share your work.