Testing is a very important and necessary part of software development. Even though many people consider it to be an essential part of the process of development, testing is often overlooked. This is mainly due to the fact that testing is generally considered boring and tedious. However, there are many tools to help reduce the pain that is normally included with testing. Some tools help test individual units (or parts) of a project, cxxTest is one such tool. There are also debuggers, such as gdb that may aid in the process of fixing the errors found while testing.

                Unit testing, as it is called, is one popular way to test software. Unit testing infers that each "unit" or part of the source code is tested individually. Normally, unit testing is an easy form of testing when the object oriented programing discipline is in use. When many "objects" exist, it is easy to test these parts individually. Another form of testing (referred to as regression testing), tests older parts of a program after a new part has been introduced. When new features of a program are introduced, they sometimes conflict with previous functions. Regression testing tests to ensure new parts of a program comply with the other, older parts of a program.

                CxxTest is a unit testing framework that attempts to reduce the amount of tedious work needed to properly test a program. It does this through the use of automation. CxxTest uses an automation script to generate an intricate set of tests from the simple header file written by the tester. The automation script makes the time required to write tests much smaller, this is due to the fact that the automation script deals with the complex requirements to write an effective test. The user is able to write the tests in a rather simple format.

                There is a slight learning curve for the proper use of cxxTest. However, once you are able to utilize it properly, the time required for testing will be greatly decreased. One thing that I would have liked to know, is the fact that cxxTest doesn't rely upon shared libraries.  This means the files required for testing are highly portable, and can be moved around from directory to directory with no problems. One just has to make sure the file path of the automation script in the makefile is correct.

                Testing, an often overlooked part of the development process, is a very important process. Many people delay testing their project until they can no longer avoid it; by this time, it is often too late to easily fix an error. Testing should be involved at every step of the development processes, enough to the point that it becomes second nature.

    Source control refers to the management of the changes made to program files and other aspects of software development. Source control also allows a team of people to develop software more efficiently. It allows the team members to work on different aspects of a project at the same time with minimal interference. Source control also normally includes references to revisions of the source code, keeping track of the differences between the versions. It also deals with source tags (normally, tags refer to major milestones in the project), and branches (different versions) of the source code.
Subversion, abbreviated SVN, is a source control program that automates the process of controlling revisions of source code and other such documents. Subversion is freely available from the developing company, Apache. Subversion stores projects in a password-protected repository on-line, allowing access from multiple computers. The repository used for this class is stored on the University's servers; however, some companies (ex. Google) host servers available to the public.

Why Source Control?

    Source control allows the development of large scale projects to proceed in a much more efficient manner. Multiple people can be working on a project simultaneously with little or no interference from fellow team members. It also allows for a project-wide undo button. One can revert back to an earlier version if needed. As mentioned before, tags and branches of source code can be made as well. Branches can be useful for different builds of the same program (ex. 32 and 64 bit versions). Tags are equally useful when it comes to keeping track of major milestones of a project (ex. V1.0 or v1.1).

Tips Regarding Source Control and Subversion:

    Since the beginning of the semester, the learning curve I've been following is somewhat slow. One of the most major things I wish I didn't learn the hard way pertains to the copying and moving of file directories. Subversion creates a hidden ".svn/" folder in every directory that is in the repository. So, simply copying and pasting folders from place to place can cause some serious pain down the road. The major problem I experienced occurred when I attempted to revert back to our first iteration. I naively deleted the source directory and replaced it with the first iteration. When it came time to commit the changes for the next lab, I committed the changes and they appeared in our tag directory (instead of the original source directory).
    Before I realized copying folders was a bad idea, I ran across the problem stating that the folder I was trying to commit changes to wasn't in source control yet (even though it appeared in the repository). I found that the most fool-proof way around this was to checkout a new copy of the project, and submitting the changes from that copy. I believe the problem referred to the fact that the repository had a folder named the same as mine but Subversion didn't recognize it as the same folder. So, replacing the files one-by-one in a freshly checked out copy seems to work the best. I'm sure there is a better way to fix that problem, I would love to know how to since I've run into the problem a few times now. However, I only seem to run into the problem when I'm running close to a deadline, so I haven't had time to figure it out by myself.

    My overall experiences with source control and Subversion have been somewhat successful. It was a slow learning curve at first, and it lead to a few hiccups here and there. But, once I was able to get the knack of things, I became rather efficient with Subversion. It's now hard to imagine making a project like this without source control. I have a feeling source control will be a tool I utilize through the rest of my career.

Benefits:
      Being able to split up some of the work in the development process has made life much easier. As with most projects, there's at least some amount of tedious work. In the case of Iteration 1 for our project, formatting all the regular expressions was slow but mostly easy work. Being able to evenly split that work up made the development process go by much faster.

      As for dealing with the complex parts of the development, being able to brainstorm with my project partner is nearly invaluable. My partner thinks somewhat differently than I do, so being able to bombard each other with ideas normally leads to some good results. In the case of Iteration 1, we had a hard time making a regular expression to recognize line comments. Being able to bounce different ideas off of each other, made the trial and error process go much faster.

      Having a group of people also allows for a wider range of resources. My partner has taken different Computer Science courses than I have, so he was able to reference different past projects than mine to find ideas for our current project. We were also able to network with more people, to discuss and ask general questions about the project with a wider range of people.

Challenges:
      Along with all the benefits, there is also the inevitability of encountering challenges. I haven't had many problems this semester with group work. Other semesters, I haven't been quite as lucky. In the first Computer Science course I took, my lab partner wasn't much help. He would tell me every time I asked him to do something that he couldn't figure it out. Turns out, he wasn't even trying. He didn't even know how to run the programs we were writing. I ended up doing most, if not all, the work. However, since we were working as a group, he ended up getting the same grade as I did. So, accountability in a group isn't the easiest to ensure.

      Also, in some cases, a group partner of mine would get most (if not all) of a project done before I had the time to look at it. Since I wasn't able to help in the development process, I didn't understand the program as much as I had hoped. This would then feel as if I didn't know enough to continue on to the next project.

      So, to compensate for the challenges, I normally try to make sure my partner(s) are holding up their end. Using Subversion has helped me with that a lot. Checking the log and being able to see the differences between the versions makes it very easy to account for the work being done. I also try to be all around more proactive on the projects, so I don't get left behind.

      In most cases, I enjoy working in groups. Being able to work in groups is a requirement for many computer science related careers. Knowing that I'll be able to enjoy working it in a career as much as I do here makes me very sure I chose the right career path for me.