After I built the Glazed Donut, I had a wonderful opportunity to explore a similar project shinny-ssg by doing some testing and reviewing and get my glazed-donut tested as well.
Finding a partner:
I used Slack as a tool for communication to find a partner to review each other’s projects. I made a post asking if anyone was doing the project in the same language as me and one person replied. After that, I DMed Emily and yeah, we became partners.
Testing and Reviewing Code
This was my first time testing someone’s code and letting someone test my code from GitHub in public.
My Partner's Code
When I started testing the code, I felt like I was a hacker, trying to break someone else's code. I wanted to do whatever it takes to crash it. While trying to break it, I was also thinking about all the possible things to create chaos, but also sweating about my own project. Tons of thoughts have crossed my mind: “what if someone else will try to do the same to my code? Like an actual hacker? Will it break? How am I gonna approach it?”
Difficulties While Testing
When I was testing my partner’s code, it took me a while to understand whether the -i command was working or not, because it kept printing that the file name was invalid but at the same time on the line below it said that the result was in the ./dist folder. I went to the project folder but I didn’t see any folder named dist. It took me about 50 minutes to figure out where it was located. I almost gave up on trying to test it. I had to check all the folders before I could find it. So I suggested my partner to display helpful messages and maybe a full path to the dist folder, so the person knows exactly where to find the generated HTML files. Or maybe somehow place it in the project folder or something. It will improve the user experience a lot.
My Code Surviving My Partner
Knowing that someone will test my code, I just felt like I had this inner peace, that everything is going to be okay, and if not, someone is going to find the bug and you can fix it. It felt safe and relieving. There were some small bugs that I didn’t notice while testing my program by myself, so it was really nice that someone could point them out.
Issues
I Broke It:
While I was testing my partner’s code, there were a few small bugs that I found:
I would like to discuss a couple of them.
The first one was about invalid HTML markup. It was really surprising to me when I found this bug, because when I was testing the program, it did generate working HTML files and everything looked fine. Turns out it was actually missing <!DOCTYPE html> element and had a duplicate
element. You can read more about it here.The second issue wasn’t a bug, it was more of a refactoring issue, but I still felt the need to file it.
The issue was that all the methods and some variables didn't follow C# naming conventions. For example, the methods were following camel casing:
void doSomething()
{
//do something
}
Instead of pascal casing:
void DoSomething()
{
//do something
}
While the program will still work even if you give it terrible variable names, it will affect a lot in the long run when it comes to maintainability and understanding the code. More details here.
First Issues Found On My Project
My partner managed to break my program to:D
One of the issues was that I had some typos in my README.md file. I just quickly fixed it and committed the changes.
Another issue was that I was forcing a break after each line in the paragraph, but instead I had to put a white space. It wasn’t hard to fix, just had to slightly change the value of the htmlBody.
Before:
htmlBody += $"<p>{p.Replace("\n", " ")}</p>\n";
After:
htmlBody += $"<p>{p.Replace("\n", "<br/>")}</p>\n";
The last issue found by my partner was very witty and touching😆
Thank you, Emily🥰
Thoughts
I think that testing someone’s code is a good exercise to become a good Software Developer, because at that point, you become the most evil person in the world. You think about everything, even the things like putting a space between variables, name conventions, a typo - all sorts of nitpicks. I would intentionally forget something or use the command in the wrong way, just to see if I can break it. The thing is that only few people would perform this kind of torturing to their own code. Once something works, they stop trying. From this, I learned that if something works, it doesn't mean it is unbreakable. When developing your software, you should think of all possible ways to destroy it. Don’t stop the moment it starts working the way you intended it to.
Final Words
Overall, it was cool to be able experience this real open source life. I have experienced so much just with one project: creating a project, fixing bugs, getting a friend, testing code, filing issues, using git and GitHub, etc😎. I am so grateful to Emily for helping me so much in testing and reviewing<3 Without her my project wouldn't be as complete. I was so happy when she replied to me in Slack because we have shared some classes and I always had a good impression from her but we never got a chance to get to know each other. Albeit, this project made it happen:D. It was challenging and fun at the same time to explore each other's code!
Top comments (0)