This week the CS467 learning module presented helpful information about code reviews. I first learned about formal code reviews Winter quarter 2021 in Software Engineering II (CS362). In the course we learned how to write unit tests and how to set up the unit tests to run with each push to GitHub. I feel like it was one of the most useful CS Post Baccalaureate required classes and wish I had taken it earlier. I believe I would have benefited from using the unit testing approach taught in CS362 on earlier projects. Currently, although I see the benefits of unit testing, I often shy away from integrating them into my projects because I became accustomed to creating projects without unit tests for so long pre-CS362.
A Code Review Learning Experience with Continuous Integration
CS362 was a great learning experience for me beyond the course material as well. One example I often think about is a project where we were assigned to work with 2 other class members. We were tasked to write code to solve 3 different coding problems, to include unit testing, and to use a Continuous Integration workflow. We were blind to how our code would be tested; it was up to us to write unit tests sufficient to catch all edge cases. We performed formal code reviews before merging each member’s contributions. When my team members completed their parts, I performed very careful code reviews and I even wrote separate tests of my own to make sure every line of code was outputting what was expected. Since we were new to writing unit tests, I did not want to rely 100% on the unit tests to catch everything since we easily could have written the unit test incorrectly without realizing it. In the end we had a project we were proud of. When we got our final grade, we ended up missing a few partial points for some minor errors. One of them was in the code that I wrote. What was interesting to me and what I learned from all this, is if I had performed the same level of code review on my code that I had on my team members, I would have easily found my error.
What had occurred is for one set of inputs the function returned an integer instead of a floating-point number. The unit test did not catch it because it did not distinguish between integers and floats (the unit test agreed that 0 == 0.0). But if I had run this through and viewed the output (which is usually what I do and is what I did with my team members code) then I would have found this out. It was a really great experience to learn that I need to watch my code more diligently and perhaps revisit it on another day and treat it like it was my team member’s code. I learned how we need to be cautious about unit tests and perhaps to consider expanding testing where needed, so for this example, a test would be necessary to specifically check the return type rather than just check if one value equals the other value.
Overall, I learned that a good testing suite and high-quality code reviews are essential to make full use of Continuous Integration. Without well written tests and thorough code reviews, broken code can still be merged into the repository.
