For this lab, the class will be splitting into two groups. One group will be writing unit tests, and the other will be doing code review - of the code for your project! See Sarah to find out which group you're in.
Later in the lab, you might have to merge your changes with changes from others! See this page for help with resolving Subversion conflicts.
A unit test is a test written to test the functionality of a small piece of code. Tests of larger subsets of the system are frequently called functional tests, but when these are automated, people tend to start calling them unit tests anyways. The idea behind unit tests is to have enough unit tests to test every code path of every small unit of code (usually methods). Then as development advances tests need to keep running (and passing). This way if some functionality breaks later, you can just run all of the unit tests, and see which ones failed to see where the problem lies. Your task for this lab is to write and commit one or more unit tests.
Sarah and Gaurub have a list of sections of code which need testing. Take one of those pieces of code, look at it, and see what it should be doing. Figure out what some valid input for that piece of code might be, and figure out what the result should be for that input. Write some code which would test that. It might require some complicated setup to get to the point where you can actually test that one snippet of code, and the code to check the result might also be large; that's the nature of the beast. Talk to your head of testing, Gaurub, to find out how to put this into a form which can be run in a batch with other tests.
Once you've got your test running in your group's testing framework, run it! If your test fails, figure out why, and fix it (remember that your test is code, too, and the test might fail due to its own bug, not necessarily because what you're testing is wrong). Make sure your fix hasn't broken any of the existing tests! After you have your test in the testing framework, and the test succeeds, commit your code to the repository. You should leave a commit message which describes the test you wrote, as well as mentioning that this commit was being done for this lab. If you don't have this information in your commit message, we (the TAs) won't find your test, and you won't get a grade for the lab. If you have time after this, write another test and commit that - every test helps your group. Commit each time you finish a test, don't bunch them all together in case you make a mistake.
Code review is walking through code line by line visually (not in a debugger). Visual inspection of code sometimes reveals more subtle errors than simply testing code's input and output in a unit test or debugger (memory leaks in languages without garbage collection, for example, don't show up in unit tests). Your task for this lab is to make at least one commit to the main repository, making some useful improvement to the code (more on that below).
Get a piece of code from Sarah (one you haven't worked on already). Read through
the code line by line, and figure out what the code should be doing. If this takes
you more than a minute, consider whether some comments should be added. Think about
what kinds of assumptions the code makes. Are these assumptions valid? If so, you
should use Python's assert statement to verify they hold for the input.
If the assumptions are wrong, and that code should be able to accept input which
doesn't satisfy some assumption the code makes, fix it. Ask Gaurub if you don't
know how to run your group's unit tests, and make sure you haven't broken any
existing tests for that code.
Once you're satisfied with your changes, commit them to the main repository. Make sure your commit message describes what you did, and declares that this commit is for this lab (this is how the TAs will find your work for this lab). If you added asserts, say so. If you fixed code, say so. If you added or clarified comments, say so. If you did anything else, say that, too!