Testing Previous WODs

Today we will be talking about program testing. For this past week, my software engineering class wanted us to test our code that we wrote for previous WODs. The WODs that we had to test were finding the sum of all the multiples of 3 or 5 below 100 (Euler Project One, link) and finding the sum of all even valued terms in the Fibonacci sequence (Euler Project Two, link). In addition to simply testing the code, we also had to fix the code so that it would adhere to our class coding standards.


To test our code, we used a plug-in called JUnit. JUnit is a popular open sourced unit testing framework for Java. With IntelliJ, I was able to quickly go through the tutorial and create some test methods for a simple Hello World program. One good thing about JUnit is that JUnit allows you to write the test methods in a separate class away from the main code. This is convenient as I remember testing C code used to be quite tedious because I would fill the main body of the code with debug macros.


Testing my iteration of Project Euler One was quite annoying at first because of how I structured my code. My code consisted only a main method that computed all the numbers. I did not have any auxiliary methods that would do the computation. Below was my original code.

public class ProjectEulerOne {
  public static void main(String[] args) {
    double sum = 0;
    for (int i = 0; i < 1000; i++) {
      if (i % 3 == 0) {
        sum += i;
      else if (i % 5 == 0) {
        sum += i;

This means that I had to write new methods to separate the code from the main method. This took me some extra time as I was trying to find efficient ways to perform this action in IntelliJ like I would in Eclipse. For my first try, I was unable to finish testing in the allotted time. Knowing that I did this WOD inefficiently, I decided to watch my professor’s YouTube video on how he did it. Watching his video showed me that IntelliJ is able to automate some of the procedures for creating tests. I learned that IntelliJ has a useful “Extract code” feature that allows you to highlight code and automatically create a method from it. Knowing this, I decided to attempt the WOD again and got my time down to 11 minutes, well within the time limit.

Next was testing Project Euler Two. Armed with my new found knowledge on how to test efficiently, I was able to complete the WOD in about 15 minutes. However, I thought this time was quite bad because I was still struggling in remembering all of IntelliJ’s shortcuts. Attempting the WOD again and using shortcuts, I was able to cut my time down to 12 minutes.

Besides writing test cases for our programs, we also had to fix the code to conform to the class coding standards. By doing this, I realized that the code I wrote previously was quite poor. Previously, I would try to finish the WOD as quickly as possible and not write comments. However, doing this actually lengthened my time when performing this week’s WODs because I had to fix many tiny issues to conform to the coding standards. I could have avoided this problem by simply writing good code that is easy to document and test and write simple comments to describe the code.

Git Issues

A minor thing that I would like to mention was that I actually ran into some Git issues when performing this week’s WODs. What I did was that I ended up deleting the wrong branch in my repository. Some quick Google searches taught me that I can use “git reflog” in my CLI to get a history of the repository. Once I did this, I was able “git checkout” the HEAD I deleted and create a branch to recover my work.


This week’s topic on testing code was quite fun and I learned some issues I had with my own coding style. I should definitely spend some time to write good methods that would reduce repeat code and also allow for efficient testing. I also need to improve my Git skills so I don’t accidentally delete the wrong branch next time.