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/