Testing & reviewing someone's code
Tags: testing, opensource
Published: 2023-09-11 16:07:18

This week I had a lab in my open-source course where I had to test another student's repo. It was somewhat challenging, somewhat not to test their project. The only challenging thing was to understand how to run their tool which wasn't that much of a challenge since I was able to get a hold of them easily for the questions I had. 

It was great working with another person to tackle the issues together. It was me going back and forth with them to get more information on how a feature is implemented and whether an issue that I'm about to file is really an issue so that I don't increase the amount of work they have to do. Most of the issues that I found on their repo were about error handling not properly done when something unexpected is passed on command line. For example, one of the issue was about output directory not being created if a file is passed to the command line that is located on the root level. It gave a standard Node.js error log which the user can't decipher because it had way too much of technical details. Besides, a couple of the issues I filed were related to improving documentation and a feature not being implemented as expected. All the issues that I filed and are explained in detail can be found here:
* [Generating HTML in .til dir](https://github.com/omalk98/TILvert/issues/1)
* [Error handling when file or directory doesn't exist](https://github.com/omalk98/TILvert/issues/2)
* [Delete til directory if it exists before copying HTML files to it](https://github.com/omalk98/TILvert/issues/3)
* [Deleting til directory manually to generate files to it](https://github.com/omalk98/TILvert/issues/4)
* [User provided output directory throws an error](https://github.com/omalk98/TILvert/issues/5)
* [Add Usages/Examples on how to use the tool to Readme.md](https://github.com/omalk98/TILvert/issues/6)

Besides, another student in the course also filed issues to my project as well. It was more or less the same experience when someone was reviewing my code as opposed to when I reviewed someone's code viz., working collaboratively to tackle the issues together. Some of the issues that were filed to my project were really interesting. For example, the reviewer filed an issue which was an improvement in my code. They suggested to use Node.js' path module in conjunction with its basename function to extract the filename out of the directory path. Initially I was doing this manually since I wasn't aware that anything like this existed. I read the Node.js documentation and found out that this can be easily done without manually splitting the string and getting the filename from the new string. It also cleaned up my code since I didn't have to perform an if/else check whether the input is a directory path or just a file. I liked how the issues were small enough for me to tackle and I was able to address all the issues swiftly. All the issues filed on my project can be found here:
* [Missing feature: users have the option to provide a stylesheet URL](https://github.com/sdthaker/Node-TILify/issues/2)
* [Upate README.md](https://github.com/sdthaker/Node-TILify/issues/3)
* [Enhance the formatting of the generated HTML file](https://github.com/sdthaker/Node-TILify/issues/4)
* [Extract filename with basename() method](https://github.com/sdthaker/Node-TILify/issues/5)
* [require() vs fs.readFile to read package.json](https://github.com/sdthaker/Node-TILify/issues/6)
* [Windows issue related to pathname](https://github.com/sdthaker/Node-TILify/issues/7)

I'm glad both the people I worked with were a good sport. Besides, while reviewing and testing someone's code I got to read & understand their code. Everyone's logic differs and in real world you have to adapt to read other person's code and this was a fantastic exercise to read, understand and learn from a piece of code that I hadn't written.