Program Design and Development

Putting in the time to setup and use unit testing can be a tiresome task, but it is well worth it in the end. I find it sometimes difficult to do something that slows down my progress in hopes that in the future it will benefit me greatly. This is my battle with unit testing, I always worry about how much time I am putting into it but in the end it always makes things run smoother. Unit testing is the practice of isolating units in a program so that they can be tested individually. These units can vary from being a single function or could be a small program. It all depends on the project. The programmer's job is to determine how to break up his project into units and test each unit sufficiently. As I said before this is time consuming and I feel many people neglect unit testing because they cannot see how something so time consuming could save them a significant amount of time in the future.

The unit testing software we used is cxxTest. CxxTest is a testing framework that we used to help streamline the way we do our unit testing. Picking the right testing framework is important. It can depend on many things like the testing needs of the project or what kind of programming environment you are working in. The thing I immediately liked about cxxTest was that was that it was simple to use. In my opinion testing frameworks have difficulty balancing simplicity and functionality. Some testing frameworks are simple to use but lack the functionality required. In an opposite case some testing frameworks have many useful capabilities but are very complex to use. CxxTest does a good job of balancing this, it is simple to use and provides enough functionality for what is needed to be done.

To use cxxTest the first step is to make the header file where you wish to make your tests. As an example I will talk about how we tested our readInput function. As said the first step was to use make the header file which we called "readInput_tests.h". Now if we plan on using the cxxTest capabilities we first need to include it. This is really simple, at the top of our header file we simply included the test suite, "#include <~path to suite~/TestSuite.h>", and the function header file, "#include "readInput.h"". Secondly you need to declare a class that inherits from it, "CxxTest::TestSuite". After this we could begin writing our tests. This was really easy to set up. Now we had access to many functions such as TS_ASSERT() and TS_ASSERT_EQUALS().

From this point cxxTest will use the information in the header file to actually write the cpp file that will implement the testing for you. So for our readInput_tests.h file cxxTest will automatically generate readInput_tests.cpp when the appropriate cxxTest commands are used in the compilation. We automated this process in our Makefile so that every time we compiled our code we would run unit tests on all of our code. The great thing about this is that once you make the unit tests you can reuse them indefinitely.

One of my favorite benefits from this is that every time a new unit is to be tested, all the other units are tested. So if for some reason the new unit causes some other unit to error we could catch this problem quickly. The code is not allowed to regress to a buggier state because of the unit testing that was made. This ensures quality throughout the entire development process, and in my opinion once cxxTest is implemented the addition of more tests is very simple. It is for this reason that I believe unit testing is a good idea for almost all programming projects. Unit testing has a steep upfront cost but you can view it like an investment. After you pay the upfront cost it will continue to benefit you during the entire development process.

While working on iteration one and two the advantages of source control became immediately apparent. The idea of source control gave my partner and I the tools to work together more efficiently. To me, source control is the idea and practice that involves the management of data between multiple users. To implement the idea of source control we used subversion which is the actual system that implements the practice. Source control provides the advantages of centralizing the code source, allowing multiple users to alter the same code at once, storing multiple versions of a file and it provides many other small benefits.

Having a central place to manage our code was very helpful. This central database is called the repository. I feel like it is very helpful to have a set standard where code going to be stored, and because of this I would not have to worry about me or anybody getting code from the wrong place. This also means that everybody doesn't need a copy of all the code. A user can get a copy of all the code if they want but it is nice to have the option to choose what code to actually have for myself. Another benefit to having a repository is that it is easier to track the changes that are made and who made the changes. In subversion, using the command "svn log" will bring up a log with a history of commits done. Every time a user checks in code they use the command "svn commit -m """. The log has the revision number, the user, the timestamp and the comment . Whenever I was unsure of the changes made by my partner I was able to check the log for the comment.

Subversion also offers a lot of tools to help programmers alter the same code at the same time. Each programmer can get a copy of the code at the same version number and when the last programmer to commit the changes does so subversion will merge the changes. Sometimes subversion cannot complete the changes without user help and this is when a conflict arises in this situation. The last programmer will then accept his own changes, the first programmer's changes, or both. When I personally had a conflict, subversion brought me into the .cpp file and showed me the differences in the two versions. From there I could look at both of our changes and implement both changes at once. I found this extremely useful in resolving conflicts.

Source control's benefit of managing multiple versions of files at once works very well with the trunk and branch model. All the versions of the trunk are automatically saved and whenever a branch is made all of those versions of the branch are saved as well. To ensure the local copy is up to date a user can use "svn update". Subversion will automatically update the local directory. If a newer version of code does not work well the simple "svn revert ..." command can revert the version back to the original subversion repository version. This was really nice for fixing mistakes and having a backup.

There were other useful commands in subversion that I found helpful as well. The command "svn diff " was helpful when I wanted to track the changes I made currently from the older version. The command tells the user the difference between the and the version of that is in subversion repository. Subversion also has "svn help ", which gives documentation on all its commands. The last parameter is optional. Whenever I was unsure on how to use a subversion command I would first look at the documentation provided by "svn help".

Tackling a programming project as a group rather than as an individual changes the way the project is constructed. The group approach in my opinion creates a more successful outcome but adds new challenges as well. My experience with iteration one has definitely favored group work above individual work. In iteration one we had a few setbacks because of multiple people working on the same project but the benefits of group work far exceeded those challenges.

The first challenge that we encountered from group work was communication error. When working as a group my partner and I would sometimes interpret each other wrong or there would be a lack of communication. For example, sometimes we would work on the project at the same time and when we checked in our code one of us would get a code conflict. The solution to this problem was obvious to us. We just needed to communicate more. Whenever one of us began working on the project we made sure to inform the other. This was an easy problem to resolve and we haven't had a code conflict since.

Sometimes one of us would have a really good idea but explaining the idea to the other partner would be another setback. It can be difficult to express your ideas about code in words sometimes and this would delay our progress at times. Our response to this problem was to write pseudo code to the other partner to help them understand. Usually this was enough to at least convince one another to move forward with the code.

Our second challenge was the problem of conflicting ideas. We would find ourselves at a point where we both think our own idea would be the best and cannot decide which to use. In this situation we would pick one or more of the following options. We would just pick one, we would implement both of them and compare them, we would argue until the other was convinced or we would do both when applicable. As an example when designing our linked list I used the new operator while my partner used the malloc function. Our final result ended up using both the new operator and malloc function. I think next time we will just pick a single method for code readability but in this instance it worked out just fine.

This is one of the great things about group programming though. Having different perspectives on things can really help with difficult problems. I feel like most of our success came from having different perspectives. Rather than just taking the only idea available we were able to take the best idea from two minds. Additionally, there was the occasion where one of us was just wrong and it helped things go much smoother when the other had the answer. Everybody has different strengths and weaknesses. Much of the time if I am weak in a particular subject my partner can help me and vice versa. For our next iteration I will make sure to keep in contact with my partner more to take advantage of this. I found that when we code together we make much more progress.

My favorite advantage to group work is sharing the workload. I find it a great feeling when I personally do not have all the responsibility of the project. I can count on my partner to do his work without worry. Whenever I get stuck my partner can help me figure out the solution. When we were working on simpler parts of the project, such as enumerating the regular expression types, we could break it up in half and complete them separately. I find this a particularly effective strategy when dealing with simple coding tasks.

The two components that I feel the most comfortable with is the concept of version control and modular software design. In small scale projects the benefits of a tool like Subversion may not be very apparent, but when working in larger projects with a multitude of people version control is a necessity. During my internship last summer was when I first began using version control seriously. In the work environment it immediately became apparent to me how important version control is when working on larger projects with many people. Version control optimized the way us as programmers interacted with our programs. It was easy to revert back to previous version if the newer version did not work, and any code conflicts could be easily resolved. I have had a lot of coding experience with version control, and although it may be a slight nuisance to have the obligation to reserve code and resolve conflicts, it saves a lot more time than it wastes.

Modular programming is a very effective way of making a program adaptable and easy to read. When designing a program modularly, each module performs a single function and contains all the data it needs to do so. This can add flexibility and reusability to the programming project in which it is used. In my opinion it also helps with maintaining the code. I found that since each module is blocked off the interaction between it and other modules is minimal. This is really helpful in the fact that a small change doesn't cascade throughout my program in a catastrophic way. Much of my programming in C# and Java has really supported this concept. Another advantage to modular programming is that it breaks a very large problem into many small problems. If I ever find it somewhat difficult to determine the solution to a problem, breaking it up into pieces really helps. Each of these pieces can be solved as a module, and this approach to problems alongside with modular programming can be really effective.

One thing that I really want to get familiar with better is the debugger. Things are bound to go wrong, and a debugger would be a great tool to tackle the job. I feel like debugging is an essential part of programming, even though I would like to think I write bug free programs. A debugger can really help me understand how my program works and determine the source of the problem in an efficient manner. I think I can really learn more about a debugger other than just adding a few watch variables or setting breakpoints at problematic areas of code. I am hoping that this class will give me more knowledge about advanced debugger commands and how to use them efficiently. I am also interested in a debugger because I think it plays an important role in testing code too. Sometimes bugs to always present themselves and a debugger would be an excellent. I believe that there are many uses to a debugger that I have not discovered yet.

Writing readable and easy maintain code is extremely important, and I think this is a skill that takes years of practice. Within this class I am hoping to get a lot of practice in this subject. Program requirements change, and that means that the program will need to change too. This is why I think it is important that my code is easy to understand and modify. Writing code well the first time can save a lot of time in the future. This is a very important skill to me, and it is something that I want to excel in by the time I begin my career as a computer programmer. I am hoping that this class will emphasize on writing good comments, clear loops, naming conventions, and other things that pertain to readability. I think this class will also give me the opportunity to learn from others, and apply the concept of readability to a large programming project.