The Advantages of Using CxxTest and Unit Testing

| 6 Comments

Testing is a fundamental part of any software project that involves adequate planning and foresight. If you are a business and are creating software for a client, your finished product must be thoroughly tested in order to ensure that the customer will be satisfied. There are a number of strategies for testing such as system testing, integration testing and unit testing. Unit testing is perhaps the most fundamental because it looks at the smallest testable part of code and only moves on to the next stage if this code passes all tests thrown at it. Testing frameworks such as CxxTest are also important in order to streamline unit testing and provide automation and feedback.
Throughout the course of this semester, I have found testing to be a necessary (and sometimes painful) part of all the programming I have done for the class project. For Iteration 1, I vividly remember trying to create my entire main.cpp file before doing any tests. I am not lying when I say that the first time I tried to compile my code, I got about 200 errors. Looking back, I realize that if I would've maybe tried to get only one regular expression to output the correct token/lexeme combination to start with rather than all thirty six expressions at once, I probably could have saved a lot of time and effort. This is the idea behind unit testing. Unit testing focuses on getting the smallest testable parts of a program functioning error-free before moving on to later stages of development. You can easily see where an error might be coming from since you are looking at relatively small sections of code. As the iterations and labs have continued, my partner and I have found it very helpful to take a little extra time to make sure that all of the small parts of our code are working before we move on. If they are not all working, it is generally easy to spot our mistakes.
CxxTest has been a very useful testing framework that we have used for the labs and for the project as well. It has provided an easy way to make sure that our code is running properly via simple .h files that contain our test methods. CxxTest provides the necessary C++ files to make the tests function and the user specifies what tests need to be run. The user simply builds the tests and CxxTest goes from there. This automation is extremely useful and works well for unit testing. One of the nice features about CxxTest in my opinion is the feedback that it provides. When you run tests, it can output the number of tests that failed and show you the number of tests that were successful over the number of total tests. It will also let you know if all tests passed.

When performing tests on your code, it is fundamental that you do not just do tests on your entire project after completion. You need to be actively testing while you are building your code and testing every relevant possibility in each stage. Unit testing helps do this by making sure that every piece of code that you are making is fully functional. CxxTest, with its ease of use and ability to automate unit tests, streamlines this testing process. Overall, CxxTest and unit testing provide a huge advantage to the programmer or business that decides to use them by ensuring accuracy and helping create error-free code.

The Pros and Cons of Source Control via Subversion

| 7 Comments

When working on a software project, you would often like a way to organize your project files and be able to access them across different platforms. When working on the project in a group, your situation is further complicated when all of your group members are updating files for the same project. Without any means of organization or backup, each person will be editing files and perhaps overwriting important code made by other people. In addition, once those changes are made, there is no way to reverse them. If one of your team members takes a functional program and creates a faulty one from it, the entire program is in jeopardy. Source control is a means to solve many of these issues and is especially useful in a group setting. I will discuss with you my experiences with Subversion, a form of source control, and explain its advantages and disadvantages.

When I first started using Subversion at the beginning of the semester, I found it to be a cure for many of the file management headaches that I had encountered previously when working on computer science projects. I confess that I had never even heard of source control or Subversion before and the idea behind them was truly revolutionary to me. Now, for the class project I could "commit" my progress to the repository and my partner could then access the updated files instantaneously from anywhere. The need for the two of us to sit down and work on the project together was almost completely gone. Also, Subversion would automatically "merge" any progress that the two of us had separately made and notify us when we had both edited similar portions of the project which could potentially result in a "conflict". We also did not have to worry about messing up functional code because now we would have a way to undo any potential damage that could have been made and thus we would be able to do more "experimenting" with our code. Furthermore, I did not even have to be connected to the internet in order to work on our project. We each had our own "workspace" on our computers that allowed us to work on the project from anywhere. The only time we needed to be online was when we were updating our workspace and committing any changes we'd made.

Thus far I have made it sound like source control cured all of the problems that were associated with doing software projects. However, this was not the case. Firstly, when I began using source control for Iteration 1, Subversion did not even allow me to commit to the repository or update any of the files on my workspace for reasons that were unknown to me at the time. By the time I had figured out the issue (which involved going to Professor's office hours to get help), Iteration 1 was nearly due. Due to this, my partner and I resorted to email as the sole means of communication and file transfer for most of this iteration. This example highlights a couple obvious flaws of Subversion. The main reason I was having trouble was that I was not familiar with all of the commands of Subversion and how to properly read the feedback Subversion gave me. Thus, I learned the hard way that Subversion requires a fair amount of training in order to be used effectively. Most of the problems I encountered were relatively simple in nature and it was just that I had not been told (or more likely had not remembered the TA telling me) how to do all of the commands. One of the more trivial problems I encountered was the result of me not realizing that I needed to "add" files first before committing them and thus this resulted in errors. Also, I did not know that having extra files that I did not want to put in the repository in folders that were to be committed would cause issues when attempting to commit. This brings up another flaw with Subversion. If there are errors related to Subversion in the files in your workspace, many times you can neither commit nor update at all until the problems on your workspace are solved. In Iteration 1, this fact resulted in me not being able to upload perfectly functional files due to problems related to other files in my workspace. I realize that there might be reasons that Subversion is implemented this way but in my case, I don't understand why I was not allowed to commit good, error free files.

As I have shown, source control, in particular Subversion, has some obvious flaws but I firmly believe that the problems that it solves far outnumber the problems it creates. Not only can all people involved in a software project be able to access the most up to date code and then modify and commit any changes, but they also can undo any changes that had negative consequences. Furthermore, there is not as much need for programmers to be physically in the same area since the most up to date copies of project files are available anywhere there is internet access. All in all, source control, if you know how to use it, is a very important part in any software project and can reduce or eliminate many of headaches typically involved in those projects.


In working on group projects in other classes and on Iteration 1 for this class, I have found that partners can be both a good thing and a bad thing. Having a partner allows you to divide up and focus on certain parts of a project and can relieve stress since you know that you will not have to do all of the work. The partner may also provide insight into areas of coding that you are not as familiar with. However, there are also challenges to working in a group. Conflicting schedules and disagreements on how to tackle the project can collapse a project before it has even started.

A good example of where having a partner allows one to divide up the work into a manageable size is in this class, CSCI 3081W. In Iteration 1, my partner did a large amount of the debugging after I wrote the majority of the code and thus, we were able to divide up the work fairly evenly. This was definitely a benefit to me since I had homework and projects in other classes that I needed to work on that week and therefore I was not as overwhelmed as I would have been if I had worked alone on Iteration 1.

Perhaps the biggest advantage to having a partner is the fact that they may be able to help you understand requirements and code that you are not familiar with. In this class, my partner has experience in C (which I do not) and thus for Iteration 1, he was able to help me understand what I could and couldn't do in C and help me out with certain C related errors and issues. In Iteration 1, I did a lot of the coding to start the project out but got many errors when I attempted to compile it. When my partner looked through the code with me, he was able to eliminate the vast majority of the errors within thirty minutes. Many of those errors were easy fixes that I had overlooked. Thus, having a partner allows for a fresh set of eyes to look for things that you may have missed.

Working with a partner is not a cure for all of the problems one faces in projects and often there are problems that will result from the fact that one has a partner. In some of my other computer science classes and to an extent in this one, trouble with being able to find a time where both partners could sit down and work on the project together actually resulted in some significant coding time being lost. In Iteration 1, the fact that my partner and I were not able to meet and fully understand how to attack the project until three days before the assignment was due caused a great deal of stress for me (and undoubtedly my partner as well).

Having a partner with a completely different view of how to tackle a problem can be perhaps the biggest hurdle to overcome when trying to tackle a project. This situation occurred in CSCI 1901 last year. My lab partner was undoubtedly smart and could satisfactorily complete projects that were due, but his way of thinking was significantly different than mine. I often found myself overthinking problems because I could not understand how my partner wanted to approach the problem. In CSCI 1902, I worked alone for the majority of my projects and ended up not only understanding the materials in the projects better but also completing them in a more timely matter. Thus, sometimes not having a partner allows you to understand the material better by not allowing you a crutch to lean on (your partner) when you are doing the project.

As you can see, there are both large advantages and disadvantages to having a partner when working on a coding project. With a partner, you can very easily divide up the work into manageable sections and with two sets of eyes, if you don't exactly understand how to do something, chances are good your partner will have a better idea of how to do it. As I said, you can also run into differences when scheduling to meet with a partner and in philosophies of how to approach a problem. Thus, if given the choice of whether or not to have a partner for a coding project, you should understand the advantages and disadvantages of having one. Only work with a partner if you and that partner have similar schedules and more importantly if you both think and approach the problem in a similar manner.

In working on group projects in other classes and on Iteration 1 for this class, I have found that partners can be both a good thing and a bad thing. Having a partner allows you to divide up and focus on certain parts of a project and can relieve stress since you know that you will not have to do all of the work. The partner may also provide insight into areas of coding that you are not as familiar with. However, there are also challenges to working in a group. Conflicting schedules and disagreements on how to tackle the project can collapse a project before it has even started.

A good example of where having a partner allows one to divide up the work into a manageable size is in this class, CSCI 3081W. In Iteration 1, my partner did a large amount of the debugging after I wrote the majority of the code and thus, we were able to divide up the work fairly evenly. This was definitely a benefit to me since I had homework and projects in other classes that I needed to work on that week and therefore I was not as overwhelmed as I would have been if I had worked alone on Iteration 1.

Perhaps the biggest advantage to having a partner is the fact that they may be able to help you understand requirements and code that you are not familiar with. In this class, my partner has experience in C (which I do not) and thus for Iteration 1, he was able to help me understand what I could and couldn't do in C and help me out with certain C related errors and issues. In Iteration 1, I did a lot of the coding to start the project out but got many errors when I attempted to compile it. When my partner looked through the code with me, he was able to eliminate the vast majority of the errors within thirty minutes. Many of those errors were easy fixes that I had overlooked. Thus, having a partner allows for a fresh set of eyes to look for things that you may have missed.

Working with a partner is not a cure for all of the problems one faces in projects and often there are problems that will result from the fact that one has a partner. In some of my other computer science classes and to an extent in this one, trouble with being able to find a time where both partners could sit down and work on the project together actually resulted in some significant coding time being lost. In Iteration 1, the fact that my partner and I were not able to meet and fully understand how to attack the project until three days before the assignment was due caused a great deal of stress for me (and undoubtedly my partner as well).

Having a partner with a completely different view of how to tackle a problem can be perhaps the biggest hurdle to overcome when trying to tackle a project. This situation occurred in CSCI 1901 last year. My lab partner was undoubtedly smart and could satisfactorily complete projects that were due, but his way of thinking was significantly different than mine. I often found myself overthinking problems because I could not understand how my partner wanted to approach the problem. In CSCI 1902, I worked alone for the majority of my projects and ended up not only understanding the materials in the projects better but also completing them in a more timely matter. Thus, sometimes not having a partner allows you to understand the material better by not allowing you a crutch to lean on (your partner) when you are doing the project.

As you can see, there are both large advantages and disadvantages to having a partner when working on a coding project. With a partner, you can very easily divide up the work into manageable sections and with two sets of eyes, if you don't exactly understand how to do something, chances are good your partner will have a better idea of how to do it. As I said, you can also run into differences when scheduling to meet with a partner and in philosophies of how to approach a problem. Thus, if given the choice of whether or not to have a partner for a coding project, you should understand the advantages and disadvantages of having one. Only work with a partner if you and that partner have similar schedules and more importantly if you both think and approach the problem in a similar manner.

What I Hope to Get Out of CSCI 3081W

| 10 Comments

Being a sophomore computer science major at the U of M, I have completed two introductory programming classes and one class in discrete structures. These courses have prepared me for many higher level ones in various ways and more adequately in some areas than others. I've gained quite a few useful skills in the two programming classes that I mentioned above but I am by no means an expert programmer. In these classes, I have most notably gained the ability to accurately comment my code and to follow the specifications and requirements listed in assignments. However, I have struggled to write code that is easy to understand and that accomplishes something in a non-awkward way. I also lack many of the C++ skills that will be necessary in the class and this will make the course a challenge.

Let's begin by talking about code commenting. When I started out in CSCI 1901 last fall, I didn't really know what putting comments into code meant, having not programmed more than 10 or 20 hours in my life. In 1901, I commented code for a lot of small programs and learned how to effectively tell the reader of the code how the code worked in a few simple sentences. For CSCI 1902 the following semester, I had to make much bigger programs such as a bus route simulation and movie database. These projects required not only more extensive coding, but also a deeper understanding of how the code worked in order to effectively communicate to the reader, through commenting, what the code meant. It was even more important for me to have organized code since unfortunately I was generally disorganized in the making of my code and I typically had code that in itself was hard to understand. Thus, although it was the case that I was sometimes messy and maybe not organized in the best way in my coding, I was able to make up for it with my quality commenting.

Achieving all of the requirements listed in a software project is no small feat especially since the requirements in a real project can change throughout the process of developing the software. In 1901 and 1902, we were typically given the requirements for our projects right away and we really did not have to worry about anyone changing the requirements throughout the project. However, we had many requirements, especially in 1902. Accomplishing all of these was not easy and required many small steps and a good approach to tackling the program in increments. I usually chose to use a method similar to the iterative approach that we have talked about in lecture. This helped ensure that each of the requirements worked well before moving on to the next step. This really has given me a solid software development foundation that can be built upon throughout this semester.

Even though I can usually wrote code that accurately accomplished the necessary requirements of a project, I definitely was not the best at accomplishing this in a organized manner and I typically had code that in and of itself was hard to understand for the casual reader. This is something I hope to improve upon this semester in 3081W. Sometimes in my rush to get some code into a program, I would not think to do simple things to keep my code easy to understand such as naming variables in easy to understand ways and declaring variables at the top of classes and methods. This would have adverse effects on everyone from the teaching assistants who would guide me in the right path throughout the project, to the graders, to myself when I was attempting to build upon or comment the code in a later stage of the project.

Another big hurdle that I will need to overcome in this class is C++ and its use in projects. Unlike many students coming into the class, I do not have any experience in C++ or even C (which is fairly similar to C++) and this is a setback that could make me struggle to keep up with material presented in lab and any code examples in lecture. I do have some experience with object-oriented programming having used Java last semester but there are still many areas that I am unfamiliar with in C++. For example, the use of pointers in C++ is also a tricky subject that I have not delved too deeply into with my experience in Java. Also, although I do have some experience with classes and inheritance, I do not have much experience with say exception handling or assertions.

So the bottom line is that even though I feel that I have probably been prepared enough to take this class, it will be a very challenging class that will force me to become a better programmer in order to succeed. I definitely look forward to gaining some valuable skills and I would like to walk away from this class with a much better understanding of software development and how to develop code in an efficient and yet easy to understand way. I would also like to be able to add C++ to the list of languages that I know how to effectively program in. Although these may not be easy tasks to accomplish, I think this course will focus on some areas that I could really improve upon and that it will help me achieve my goals!

Recent Comments

  • basse055: Andrew, I really liked your personal story about compiling all read more
  • zdonx015: Your story of getting 200+ errors on your first compile read more
  • vangx568: You show good knowledge of unit testing. I'm not too read more
  • mani0116: Unit testing is incredibly nice at seeing how specifics seem read more
  • tric0035: It is good that you did not fall into the read more
  • anwar010: The CxxTest suite has been quite convenient in simplifying my read more
  • basse055: Andrew, That also bothered me that you sometimes can't commit read more
  • ryan0286: I don't think you necessarily point out any "obvious flaws" read more
  • nguye932: Source Control has taken huge burden off of me and read more
  • norhe003: At first, I did not understand that learning subversion was read more

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