Apparently we did learn a notion earlier about "writing test cases before coding is better" because not only does it help us find bugs during coding progress, it does not take much time either to write them in advance. I personally think that if you can write some good test cases before even you start on coding, you can get a better idea of what kind of result that you are expecting and thus make you to think more about the requirements as they are not always explicit or easy to comprehend, not to mention that they tend to change after a certain amount of time.
As for its glorious definition, unit testing is a piece of code that exercises a very small, specific area of functionality of the code being tested. For example, I believe almost everyone of us had encountered the awful segmentation fault compiling errors most of the time. And what I usually did to find out which part went wrong was to merely locate several simple "printf" statements in different segments of the main code and try to trace it down to figure out at which point the segmentation fault begins. From this you would be certain that those codes before that point were "safe" - they were free from syntactical errors and were compiled successfully. This helps you to determine whether your functions work as intended. This is especially helpful when you want to find bugs that embed themselves somewhere in a loop condition. If something goes wrong, all you have to do is to locate several "printf" statements in that loop and compile the code and check if some of the loop iterations failed.
CxxTest is just a simple testing framework designed specifically for C++. In iteration 2, the test cases that we had depend solely on this framework to test our code functionality. Although I personally was kinda clueless about what's going on with all the files in this CxxTest directory, I was certain that this testing framework will come in handy after we build the linked list of tokens and want to check if the linked list is successfully built and not broken somewhere in between the token nodes. Had we not introduced to this, I assume it would have been painful to check that, especially when we were also supposed to deal with the token terminals and token lexemes in each token nodes, not just the linked list structure. So what we had to do in order to complete for iteration 2 was to feed the test cases with corresponding input and make sure all of them pass. Though getting a bunch of failed test cases error might not be fun, it really helps us to know which part of our code was not working and helped us to think even further about why different implementations yield different test cases error. And we can compare and check and edit accordingly.
