I c u Test

Unit testing is an important part of designing and developing code. Here are 5 reasons why.

1. Unit testing allows you to test your code all the time, in an easy way. Instant gratification, if you will.
2.  If one starts unit testing early in the process of writing their code, then it leads to a better design.Your method names and classes will be based on the tests you write and can therefore help you organize your code.
3. Unit testing allows one to make changes very easily to your code later down the line. Developing a good baseline of tests, lets you refactor you code easily because you know it works allready.
4. Since unit tests actually "test your code," you can "try to break it." This will give you an understanding of your code you would not have if not testing.
5. And the most important (for your boss)

This Is Why Unit Testing Is Important

CxxTest for C++ is a very nice way to write unit tests and do unit testing in C++. Cpp files are generated with perl from your regular classes and then you compile those and run them. You therefore do not have to declare your tests in your regular code and can just attach their framework to do your testing. It even has an awesome plugin for eclipse that lets you easily write tests and use them through a gui.

Some of the features (as taken from its own description):

•     Doesn't require Runtime Type information.
•     Doesn't require member template functions.
•     Doesn't require exception handling.
•     Doesn't require any external libraries (including memory management, file/console I/O, graphics libraries.)
•     Is distributed entirely as a set of header files.

Testing is done by writing test cases mainly with a function called TS_Assert(). It works very similar to the standard Assert() macro. You just put whatever function you want to test inside it say,

     TS_ASSERT( 1 + 1 > 1 );
or

     TS_ASSERT_EQUALS( square(2),4 );

Sauce Control

Source Control is an important part of the daily programming grind. Every morning we wake up, brush our teeth, and head on to other daily activities. And every afternoon we might continue the constant process of committing our changes and updating to the latest version of our code. But what are these two things I have already mentioned, Committing and Updating? And which source control method are we even talking about?

You can read a concise history of Subversion here, but essentially, a previous sauce control schema called CVS lacked in certain features and a few developers let out to create a new system.

svn checkout — Check out a working copy from a repository.

This is the first thing one does when working with a repository of code. You check out a copy for making changes. Now how do you put those changes back?

svn commit — to send changes from your working copy of your own version of the code to the repository.

SVN's best feature is the ability to work on a shared code base. This code area is called the Trunk. The Trunk is where the full copy of your code lives all time. When one commits code to SVN they are adding their changes to the trunk.

 svn update — Update your working copy of the code from the repository.

Updating will bring the latest version of the code from the repository to your machine. From that point the developers using the repository can make changes to the updated versions and then commit those changes to create a new, updated version of the code.

These two features are great but lead to one issue. If two team members are working on the same file, make changes to that file, and then try to commit, they will hit a snag because of an out of sync code base. Luckily my team has not had this problem yet. The process can be resolved with what is called a merge.

svn merge — Apply the differences between two sources to a working copy path.

A Merge is when a developer looks at the changes to his/her local version of a file and the changes made to a Trunk file that hasn't been updated on the local version, and fixes the synchronization issue by amending the code to include both updates or one of the updates. There are 3 possible outcomes of this process.

• Override and Update: In this case, the local version of the file is discarded and the Trunk code overwrites everything. 
• Override and Commit: This is similar to Override and Update, but the Trunk code is overwritten with the local version.
• Merge Changes: In this solution, both changes are merged into the local version and (s)he is able to commit the file and overwrite the Trunk file.  

Now you might ask, "How am I supposed to know what the differences in the files are?" well SVN has a command for that too.

svn diff  — Display the differences between two paths (files).

During the process of Commiting, Updating, and Merging, the code base can change quite drastically.  If a problem arises, backing up your data is key to continuing a project without major losses.  SVN provides a way to backup your code via Tags.

A Tag is a snapshot of your code at a given time.  It is similar to a Trunk but it is assumed a Tag will not change in the future.  This is useful if a situation arises where it is necessary to revert your code base to a prior state.  In larger environments, Tags are created with each build. Version 1.0, and so on. Luckily, we have never had to revert back to a tag yet in our project.

Just in case you need to offshoot your code for some reason, say to introduce a new developer to your code, and you don't want them working in the Trunk, SVN has something called Branches, They are a separate Trunk-style project used for work on the project.  Branches can be created from existing code bases, including the Trunk and Tags.  Even better, you can Merge between a Branch and the Trunk to bring in changes from the temporary project that need to be implemented into the code base.

For full technical information on command syntax and even more in-depth information. http://svnbook.red-bean.com/

Partnership For the Win

With an hour left before the deadline, tensions are high amongst partners Jim and Matt on Coding Team Alpha. Working separately across campus, they are communicating via gChat on a bug that neither of them seems to be able to find. Jim suggests that the FOR loop may be going past the allotted array indices into segfault territory. A quick change of the parameters, compile, run, and … Success! No errors. Now for the test cases. Pass, Pass, Pass … Fail. “What happened?” asks Matt. “The last test case failed” types Jim. “Let me take a look at it, Go ahead and commit” says Matt. Jim commits the code to their mutual repository and Matt updates his version. While merging the changes, he notices the conflict.  His code detects the “to” keyword, and has the regex backend working properly. The repository does not. He compiles and runs his version. “Mine just passed all the tests” types Matt. “I added the “To” parser while you were working on that loop.” With all test cases passing the final version is committed and tagged. With the deadline now achieved, both members continue on with their nights. Although my partner and I finished days before the deadline, I can remember situations in the past where I was in this predicament.

This example shows both benefits and challenges to working and coding in a group of two people. To go into further detail on the matter, I will start with the challenges. 

Early in this iteration, my commit messages to subversion were "Less than stellar" as my partner put it. I would record what changes I did, but would fail to remember exactly everything I changed in that revision. And I would hope the diffs of the files would explain what I forgot. The problem though, was not my partner understanding the changes themselves, but why I changed what I did. He gave me a format for commit messages. The first line is basically a summary of the main changes or a title. The preceding lines are explanations of the why the changes occurred. With this format I eventually got the hang of committing verbosely and not just trying to save time.

Our next challenge was dividing the project. We never formally discussed this. My mentality was just to work on it as much as I could. And hopefully we would get done early. It might have been a good idea to assign work to each of us even though the workload turned out semi-even.

There were many benefits I realized over the course of the project that I am grateful for, the first being the existence of subversion. Trying to wrangle email threads or flashdrive swapping or the always hilarious “emailing the code to yourself” are all methods that should be left in introductory classes. I wish I had known about subversion much earlier, I would have set up my own repository for every project I have done since. Next is the parallel aspect of 2 people. As merge-sort proves, dividing something in half makes it go faster. I was actually out of town the weekend before the deadline. I had worked on the project up to that point, and my partner took over the work for the weekend. When I came back, we joined back up and finished the project. 

It all started with Scheme

A language of balanced parenthesis: it was the bane of my existence in my first programming class. I can remember my classmates hating the textbook for the class, but I actually enjoyed reading it. This class taught me how to program side by side for the first time. I happened to have a partner that had taken a c++ class who really taught me about abstraction and other basic coding techniques. And I was learning the semantics of scheme faster than he was, so I would sit at the computer and type while he figured out how to organize our railroad program. I had no idea that this was actually a coding technique, I just thought that the system worked well and therefore we should use it.

My next programming class taught me about IDEs and Google Code repositories. It was these two tools that would shape every programming assignment and CS class up until right now. Eclipse was suggested as a tool that we should use for our first object oriented language, Java. Here is a list of everything I love about my IDE:

• Automatic formatting and indentation correction
• Renaming a variable or function in multiple places at the same time.
• Automatically generating “dumb code” (getters, setters)
• The vast library of plugins available (SVN specifically)
• The organizational concept of projects and a “Workspace”
• Support for every language I have had to deal with thus far.
• Extremely easy-to-understand debugging.
• Mouse-over documentation popups
• Autocompleting functions
• Generating Classes
• Automatically generating comments
• Automatically generating documentation

Google code taught me how to share my code with a partner efficiently, so it was easily maintainable, and so that we could both work on it and merge all changes together after one of us had completed a part of the assignment.

What I am unfamiliar with in this class is the concept of software modeling. I have always had the problem of knowing almost exactly what I want to build in my head, then drawing it, but having trouble translating it to code. I had no concept of UML until I bought our textbook for the class, and I feel having an actual knowledge of a real system will benefit me in this area. I also am very interested in code generation from these diagrams. Efficiency and automata are some of my favorite things, and any product that can do those, I am going to use.

Another unfamiliar topic I have always wanted to learn about are regular expressions. I would read xkcd all the time and wonder what the hell Randall was talking about. And now I am starting to learn exactly how powerful they are. A very useful search program i use on a minutely basis, Everything, supports regexes and now that I slightly know what I am doing, it has made searching much more accurate.

edit 10/3/11, incorrect link to "everything"

1st

Everybody needs a blog right?

My name is Andrew Bork, and I am a senior CS student at the University of Minnesota.
The purpose of this blog is to record my experiences in my future career and to serve as a required blog for a class I am taking, CSCI 3081 Program Design and Development.

http://www-users.cselabs.umn.edu/classes/Fall-2011/csci3081