November 2011 Archives

Blog 4 Testing

| 3 Comments
    So far this semester, my partner and I haven't really wrote any unit tests for our project. Besides writing tests in the lab exercises, I have never used cxxTest. I understand the importance of unit testing, but when we write our code we try to make sure it outputs the same data as the sample output given to us and we don't do this until we finish writing almost all the functions.
    cxxTest is a testing framework for c++. I don't know how if there was some installation behind the scenes before we started using cxxTest, but when we first used it we extracted cxxTest in a specific directory structure within our group repository. After that, cxxTest just worked. It was quite fun writing small tests and seeing it run in lab. It's the only testing framework that I know of for c++ and for our purposes, I believe it's sufficient. I don't write a lot of test cases and I don't know how to write more advanced testing techniques.
    Writing code and testing each function before moving on to the next is helpful and ensures that you can be confident in your code working and this is what unit testing is for. This practice can save a lot of time in the long run. When we were programming for iterations 1 and 2, we didn't run our program until we thought we were finished. Only then, did we compare our program's output to the expected output, but before we could even do that we ran into a lot of errors that we were unsure of. We spent hours trying to figure out what was wrong. Was it our regular expressions? Or was it something we missed in our consumeWhiteSpace function? Maybe we didn't correctly output the data in our printout method? This would not have been so hard to debug if we would have wrote unit tests. It would have helped us to eliminate many factors and pin pointed us to a more exact cause of the error.
    Ideally, writing unit tests through cxxTest is a very good way to program big projects, but my partner and I just don't do it. Perhaps it is just a bad habit of mine not to write small tests to make sure all the underlying methods work before I move on to the next method. Since unit testing is used for testing small parts of the whole program I don't think a lot of time will or should be spent on it. As it focuses on a small portion of the overall code it may still miss some unforeseen errors.

Blog 3 Subversion and Source Control

| 3 Comments
    Source control is a way for software developers to maintain and manage code. It is a very useful tool when working on a large project with a group of people. Using source control allows team members to work on the same code files from different locations and times and keeps all files in sync. Another very useful feature of source control is the ability to roll back or revert to an earlier version. We've run into situations before in lab where we messed up a file tinkering around with our makefile. It changed all our code in a file into jibberish. But luckily for us, we were able to revert that file to a previous version via svn revert ourFile.
    For our WTF Project we have been using svn as our revisioning control system. It is terminal based and, for our purposes, simple and powerful enough. Using svn allows us to work on a local directory and upload it to a repository when we commit it. Uploading it to a repository means that any team members assigned to the repository can get the latest version to their local directory by updating. This means that any team member can work on the files from anywhere, at anytime and commit the changes to the repository so that other team members can update their local directory from anywhere and anytime. Of course this committing and updating requires good communication across the team otherwise there will be conflicts when committing and updating.
    When all team members are able to communicate effectively, running into conflicts will almost never occur. So most of the time, using svn to commit and update is very easy. But when there are conflicts, perhaps using a source control with a gui would be easier. In svn when you run into conflicts, it can be quite hard to figure it out. Sometimes it is just a simple merge of code and reviewing it and then resolving the conflict. And sometimes it has to do with hidden svn files and directory structures that can cause a lot of confusion and trouble. But when it comes to a situation like that and I can't seem to solve it, I just backup the files I've changed to a different directory and delete the whole local directory and check it out. After the checkout, I just copy the code from the backups to the local files and commit.
    So for anyone planning to use svn, the main commands you need to know are: checkout, update and commit. Everything else can be Google'd when it arises. Use checkout for a fresh local directory copy of the repository. Use update if you already have a local directory to get the latest version from the repository if any, I always use this before I start coding away. And finally use commit when you've made changes to files, so that it uploads the changes to the repository. Also don't forget to use the -m for committing files, it allows the person committing the changes to comment what he/she is updating/changing. This is very useful when the group is planning to go back to a certain revision number.

About this Archive

This page is an archive of entries from November 2011 listed from newest to oldest.

October 2011 is the previous archive.

Find recent content on the main index or look in the archives to find all content.