Learning about Version Control and Unit Testing

Lyaiera

Two separate requests. I'm doing a CS course and I want to get a start on learning about Unit Testing and Source/Version Control. What should I be reading to figure those out?

Seridisand

For version control, I'd look at the three main(*IMHO*):
Subversion - very easy to get to grips with, I'm a linux user so I've never used this beyond the cli, its been up on the apt-repo for as long as I can remember and is simple to install
Mercurial: not really familiar with it
GIT: Very Popular at the moment, you can use a service like Github,com, set up a free account and run through their tutorial(takes about 10 mins) and you'll be able to use it and work towards a neat tricks of tracking and branching with time

Unit Testing:
Python: TestCase Library
Java: JUnit is useful

srsly78

Nothing really (manual aside), just go mess around with github. As said above, alternatively you can learn another system.

Learn how how to commit and update. Then move on to more advanced stuff like branching and merging etc.

Colonel Panic

Since I'm a fan of Mercurial, I'll just link a good intro to that.

http://hginit.com

You wouldn't go wrong looking at any of the systems mentioned so far though.

Aswerty

Colonel Panic wrote: »

Since I'm a fan of Mercurial, I'll just link a good intro to that.

http://hginit.com

You wouldn't go wrong looking at any of the systems mentioned so far though.

A great mercurial tutorial. The Subversion Re-Education page can be skipped if new to version control.

I learned version control and unit testing by myself about 3 years ago and didn't have any colleagues/lecturers to lean on at the time. The following is my take on it.

The choice as far I saw it was either go with Subversion which is a traditional centralised version control software (CVCS). Subversion is pretty dominant in the CVCS arena. Or go with the more modern distributed version control software (DVCS). Git and Mercurial are the big ones in this instance though Git is definitely more popular but they are very similar. I went with Mercurial since it seems to have a shallower learning curve. Version control recently has very much been looked at as CVCS vs DVCS and in a lot of cases DVCS is becoming the de facto standard although CVCS is still very popular and can be a better option in a number of scenarios. I first started using a GUI interface (TortoiseHg) but found it was hindering my understanding of the fundamentals so I switched over to the command line interface and haven't looked back since. If you go with Mercurial or Git I can't recommend Github (Git only) and BitBucket (Git or Mercurial) enough to be used as your central repository.

With regards to unit testing I understood the concept of it pretty easily but it took me a short while to understand the practical side of it. A pretty succinct example of a unit test is:

// multiplies two numbers
public float Multiply(float num1, float num2)
{
    return num1 * num2;
}

// unit test to verify the Multiply method can correctly multiply two numbers
public bool VerifyMultiply()
{
    // arrange
    float num1 = 20;
    float num2 = 5;
    float expected = 100;

    // act
    float actual = Multiply(num1, num2);

    // assert
    if ( actual == expected)
        return true;
    else
        return false;
}

As you can see we can unit test without a framework but in most cases people will use one, such as JUnit for Java which was mentioned earlier. These frameworks allow you to easily run your unit tests so you don't need to worry about calling the methods that contain the unit tests. The frameworks also contain lots of goodies to verify the method under test works as expected. Unit testing can also be used to verify a method will break (e.g. throw an exception) under specific conditions.

In my above example I use the AAA approach which is to first setup the test variables (arrange), call the method being tested (act) and then assert a specific outcome (assert). Typically you only assert a specific scenario per test and you can have multiple tests per method if needed.

One thing to understand about unit testing is that it forces you to write loosely coupled code. This is because it can get pretty frustrating attempting to test a method that is tightly coupled to databases, the file system and god knows what else. Dependency Injection frameworks are the next step in my view once you nail down unit testing but I wouldn't look at them before hand because they can be a bit WTF at first.

All in all though Srsly78 hit the nail on the head, just go implement version control and/or unit tests on existing projects or even start a simple project. Reading in depth about these technologies isn't all that useful until you understand them at a practical level.

Merrion

Also unit testing can lead on to test-driven development. There's a worked example I did on CUSIP validation that may be of interest.

When writing unit tests, always initialise the "expected" value to be different to the "actual" variable value. This is so that a test can only pass if that variable value is changed by the test.