CSCI 3081

Unit testing is the process of checking that a small component of a program gives the desired output given a series of inputs. This breaks down the large project into smaller goals. This is an important part is an important part of program development. It allows us to assure that our program is behaving as designed. Whenever a reproducible error comes up where a bad input breaks the code, it is a good idea to add that bad input as a test case.

This is closely tied to regression testing. Regression testing is the process of making sure that newly written code does not have a negative impact on existing functionality. It is a good idea to incorporate all unit tests into regression tests to ensure that they work of the rest of the project's development.

One approach to development that I support is test-driven development. In this method, you write a suite of tests before programming that test the desired operation of the program or function. This is effective because it forces you to clearly define what should happen on a variety of inputs before beginning to code and can help identify how to edge cases such as null input.

CxxTest is a testing framework for C++ written in Perl. When it runs, it displays how many tests have passed and which tests failed. I like it because it is easy to write a test suite using TS_ASSERT() statements in a class that inherits from CxxTest in a header file. It is easy to create an automatic test script that can be run during development to get an indication of progress made.

Unit testing, however, is not a silver bullet to developing good code. A program is designed to run on any potential input, but we are only able to test a finite subset of these potential inputs. One of the weaknesses of testing is it relies foresight of the programmer to think of potentially bad inputs. Another is that is possible to pass a series of tests and still not work as intended.

For the project we are developing, my group is using Subversion (svn) as version control. This is a way of accessing a repository shared by my teammate and myself. It allows us to commit changes that are then available to each other on all our machines (lab computers, desktops, and laptops) allowing us to not be tied down to a single location for the master copy. We can divide the project into tasks for each of us to accomplish and commit those changes independently.
Overall, I have had a positive experience with subversion. The ability to access the files freely on a different machine allows us to work flexibly. Luckily, we have not had to revert our project yet. I have tested the functionality and it effectively restores a previous state, which gives me the confidence to commit code knowing that it is not difficult to revert if we end up changing back to a previous structure. I have used the command line interface up to now which, while effective, is not always pleasant to deal with. I am beginning to work with KDESvn which is a graphical interface for computers with KDE. It seems to have all the functionality with a much more intuitive interface, reducing the learning curve of all the command line arguments.
I ran into a frustrating scenario when I was trying to copy to a tags directory. I attempted to do this by copying the trunk folder to a tags folder on my local machine. I now know that this is not the best way of accomplishing this since "svn cp" does a good job of storing only the differences between files. When I went to try to use svn add to mark it for addition to the repository on my next commit, I got a message saying that the folder was already under version control. As a new user to Subversion at the time, I was confused by this as I expected that Subversion would never have seen this folder before and added it. The problem occurred because in copying the folder I also copied that .svn folder, a hidden folder that is used by Subversion to track status. After deleting this from the copied folder I was able to add it as I had expected.
One of the concerns I have with Subversion is the way it handles tags. It requires us to manually copy the entire trunk to a separate folder. When the "svn cp" command is used Subversion stores the difference between files on the server which saves space. However, when these files are checked out you have entire copies of the files. At this time our project is small enough that this is a non-issue but I can imagine a scenario where having a large trunk copied into many tags would cause a project to take up a lot of unnecessary space.

I have noticed many benefits to programming in groups. The first is it forces the team to do a good job of organizing the project up front and have clear, defined goals. Having a well-defined structure and goal is a key to any successful programming attempt. As an individual, however, there is often a temptation to jump right in to coding the project. With others involved, this is not possible, as the code would take many spurious routes.
Another advantage is people often have trouble finding bugs in their own code. It looks so natural when they look at it themselves, but a fresh set of eyes can ask the question "why is that line of a different form?" and expose a simple typing error. More sets of fresh eyes can help eliminate painful errors that are difficult to trace.

Team programming also allows us to get the best of multiple skill sets. If, for example, there is an individual talented at pointer manipulation and an individual good at algorithms, they can combine these to create a strong program that is better than either of them could have achieved on their own. This is a great example of the whole being greater than the sum of the parts.

One of the things that I think is good about team programming but may initially appear as an obstacle is differences in how individuals format the structure of a code. At first, this could appear to be an obstacle in the readability of code. However, it is important to get used to working with other peoples' code, as no large projects are taken on individually. Also, it has helped expose me to new styles that I have adopted or incorporated into my own, as they can feel natural to me.

I have some basic knowledge of C++ and look to expand on this. This knowledge comes from both academic work and independent work. I look to expand this knowledge in a more formal setting and learn how this is used in industry.

I have previous experience using subversion, so this also gives me some working knowledge of version control and group program.

I am interested in learning "best practice" for program design. In the past, I have worked on projects that were small enough that I could get with an ad-hoc approach to programming. My goal was to get the program to run, and not neccessarily make it neat. It has mostly been for purely class work, and I am looking to expand my skills to real-world applications.

I am excited to see what kind of models we will use in CSCI 3081. My goal is to learn how to effectively break a large project into small, coherent, managable projects.

One thing I am curious about moving forward is what kind of development tools we will be using. So far, most of my programming experience in C++ is command-line based. I am interested in moving to a more IDE-based approach with more tools to make the mundane parts of programming simpler.