Committing To A Large Codebase

Introduction

In February 2024, I became a contributor to the open source project Open Energy Dashboard. In this article, I will describe the work completed by me towards writing test cases for the OED project.

The Codebase

OpenEnergyDashboard represents an innovative open-source initiative designed to facilitate the visualization of energy data via web browsers. This robust platform empowers individuals and organizations with real-time insights, enabling seamless access to desired energy metrics. This is particularly beneficial for people seeking to monitor energy consumption, its user-friendly interface ensures accessibility without the need for technical expertise.

This dashboard serves as a tool that offers a simplified yet comprehensive approach to energy monitoring. Its optimized design prioritizes ease of use, catering to a diverse range of users. A prime example of its utility lies in its application within universities, where it aids in tracking electricity usage across various campus facilities such as academic buildings, dormitories, and on-campus residences.

Furthermore, OpenEnergyDashboard serves as a valuable resource for individuals aiming to analyze trends in their energy usage over time, facilitating informed decisions towards energy conservation and efficiency.

OED website's line graph

The dashboard is a useful tool for energy managers responsible for buildings, facilities, or organizations. They can use the dashboard to monitor usage trends and identify areas for improvement.

OED demo site

Exploring the Issue

The part I worked on is to create a test LG3 for the Open Energy Dashboard. In this circumstance, the graphic unit is changed to kWh and units/conversions are u1, u2, c1 . We need to have daily points for middle readings of 15 + 20 minutes for a 61 day period and quantity units with kWh as kWh. The goal is to test a given file of readings against an expected file and make sure the results are as expected. This issue is important to making sure the program functions as a whole. Functions that don't work or unexpected errors should be caught in testing so that functions are using correct values and the program works as intended. I first had to read the design docs and specifically look at the LG3 test case and the requirements for that specific test case. This is where I found out about the unit conversions, the name of the expected csv file and the start/end times for our test case. After that, I went to the OED repository and found the key location to solve the test case which was src/server/test/web/readingsLineGroupQuantity.js. The "Src" folder indicates that it is part of the server-side codebase. "Web" Implies that the tests are related to web functionality such as testing endpoints or components within a web server. Lastly, readingsLineGroupQuantity.js is the specific test file that contains the LG3 test case.

Technologies Overview

Before delving into how the issue was solved, let's first examine the project's current tech stack. The following graph shows some of the main technologies in OED grouped by where they are used. 

Created by OED

Challenges

After learning about all this, I was able to come up with an idea that ultimately led to a solution.

Running application on local computer 

My biggest challenge was getting the application to run on my computer locally. Prior to jumping into solving the problem, I talked to my peers who had already done a similar test case  about what they felt was the hardest part of the project. They all said that getting it to run locally was the toughest part and I have to agree. My biggest mistake was not looking for the “ getting started ” page and instead I tried to run it without having any guidance. I cloned the OED repository and then coded up a solution that referenced the previous test case which was LG1. 

Reaching out for Help

I tried to run this and I saw that one of my test cases passed, but the other did not. I was not sure why. So I went to the project manager Steve-Huss and he told me that I needed to first run the program in a docker container. Figuring out how to get docker running on my computer was the hardest part because I was not familiar with it and I did not start by reading the “getting started” page. After mindlessly asking AI on how to get docker installed to run my project, I finally stumbled across the “getting started “ page on OED and I got to work. I was soon successfully able to run the web application within the docker web container. 

The Basic Idea

The code I wrote

The basic idea of this code is to load the data into the database, then get the unit ID to convert values correctly. After that, the expected response data is loaded from the corresponding CSV file. Then a request is created to the API for the specifically given reading times. Lastly, in line 57, the code checks that the API reading is equal to what it is expected to equal with the expectReadingToEqualExpected method. Throughout the code, a commonly seen aspect is the keyword “await” . This keyword is used inside an async function to wait for a promise to resolve before proceeding with the next code execution. This allows asynchronous code to be written in a more synchronous style which makes it easier to read and understand.

The Solution

I still had the issue with only 1 test case passing. So I tried to look at what the previous test cases did and how mine was different. I looked at the difference in requirements and execution and found that the main difference was in the csv file name. But I was unsure on how to address the csv file problem so I went to the project manager again. He told me that I needed to import the correct csv file in my cloned repository so that the file exists in the cloned repository.

I was still passing only 1 test case. I was unable to figure out the bug so I went to the project manager yet again and asked to set up a meeting with him to debug this problem together. During that meeting, he told me the basics of this application, and pointed out what the errors I got meant and how to overcome those errors. Eventually with his help, I figured out how to get all the test cases to pass by uncommenting the createTimeString method and by implementing the proper time interval into my code which was createTimeString('2022-08-25', '00:00:00', '2022-10-25', '00:00:00') and not ETERNITY.toString(). This was because my test case was specifically asking for a 61 day period of data and not for eternity. This makes sense because my error was saying that the array was reading in 75 data points when It was expected to read only 61 ( for those 61 days). By leveraging the asynchronous capabilities of Node.js, I successfully addressed the problem by implementing the correct time interval using the createTimeString method. This method is crucial for defining precise time intervals required for data retrieval.

Passing test cases

The commit I made affected the OED website positively. Due to the LG3 test case, users can now narrow down the energy usage to a 61 day period so they can have more flexibility in seeing what happens in those days instead of only being able to see a larger version of the energy chart that could go from 3-4 months of data. To show that I did all of this, here is the Pull Request Link