A reflect for Lab 8

As a programmer who usually makes mistakes (sometimes dumb mistakes) I found the content of this week is pretty relevant and useful to me. Since programmers are humans and humans make mistakes, writing unit tests to dig out the potential issues in our code is as important as implementing features.

Which Unit testing framework did I use? and why?

To implement Unit Tests for my project, I dug through the google search result and GitHub and I found that it's quite opposite to the notorious fame of C++ that C++ is a very old-fashioned and anti-developers language, there are actually quite a few unit testing frameworks for C++. The one that I chose is Catch. Just like its name suggests, Catch is a unit testing framework for C++ to catch potential bugs in the code by writing unit tests. Not like other testing frameworks, catch only requires writing very few amounts of code to set up a unit test, this means I could be focusing on my actual test logic rather than being drawn away by the unit testing framework itself.
It's pretty easy to set it up, as the documentation shows, I only downloaded a header file catch_amalgamated.hpp and an implementation file catch_amalgamated.cpp to add Catch to my project. For setting up the Unit Tests, I read Catch's document and found out the process for me to set up Catch should look like follows:

1. Create a .cpp file to save unit test code and include Catch's header file in it.
2. Use TEST_CASE() to specify a test case and SECTION() to segregate the test case with different types of wrong arguments that get passed into the target function, although this is not required, it's still recommended for a more readable report file.
3. Inside each SECTION(), use REQUIRE() to assert the value against the expected value. If the tested code did not return the expected value, it will be counted as a failed test.
4. The result will be printed to the console and a report file named test_result.xml will be generated.

The problems I found through the Unit Tests

Just like I mentioned at the beginning of this post, I tend to make dumb mistakes by coding inconsiderately. One of the bugs I made in my code was a very typical empty-checking issue. There is a function that takes in a string of the path of the txt file to be read, and the function will open up a file stream to read the txt file to convert it as an HTML string and return it to the caller. Everything will work fine if I pass the txt file following the rule that the txt file is neither empty nor null pointer. However, if I pass in an empty string to represent the path of the file, everything will crash. This is because I forgot to add a condition to check if the parameter file path string is empty or not since I checked it on the caller side, although I know it's empty checked somewhere in my code, I still want my function to be able to resist empty values because I cannot just assume the callers have made sure that the passed string is not empty.
In the end, I was pretty excited about setting up this test framework because I knew I was going to make mistakes in the coding process, and I believe this is what makes it more worthwhile for me to set up this unit testing framework.