NetC#

Definition and usability

The integration for people that don't know what is it, the goal is to take all the source code, to build and to do all the unit tests to see if all is correct, that all things make a coherent project. Continuous says that we will do an integration as much as possible. Why? See by a concrete sample. Imagine that we have the 2 following classes: 

We have 2 developers X and Y, each having the latest version of the files. The method "StartRace" of the class CarRider makes a call on the method "SpeedUp" of the class Car. Now the developer X modifies and adds a parameter on the method "SpeedUp", he will also change the call of this method into the class "CarRider" and the developer Y add a class "TrustControlEngine" with a method "RegularSpeed" which calls the method "SpeedUp" of the class "Car". We have the following situation: 

Developer X

Developer Y

For the moment  the code builds for each developer, now imagine that the situation stays 2 months in this state and then they want to put the application in production, the result of the build would be catastrophic. This is evident that the code doesn't build anymore because the class "TrustControlEngine" uses the method "SpeedUp" without parameter. The continuous integration is necessary and we don't need to do it by hand, there are tools that can automate this work.

The tools

There are many tools, for the moment I know 2 tools:

• Team Build from Team Foundation
• Cruise Control (open source) 

The tools to do continuous integration take the latest version of all the files from a source control and check that all builds, it is possible to configure the tools to run unit tests, to analyze code, to run code coverage, ... These steps can be executed when there is a detection of check-in of after a defined elapsed time. The tool notifies us by mail (for sample) the result of the integration.

Sample of a structure that I setup with some tools: 

The development's process is made of some steps that we do to create our software. The process that was very used in the past and that seems natural is the process named "Waterfall" by comparison  with a water fall. In this process we begin by all the analysis, next by all the development, next all the tests, next the demo and the the release. That can be illustrated as :
 
One of the big problem with this method is that we see a problem too late, what we do if when we show the application to the end user if this one says that the application doesn't meet his need because we misunderstood what he wanted and this has an impact to the rest of the application, we redo all?

The process by iteration can solve this problem, we split the work into small steps where an iteration is made of the same steps as the "Waterfall"  but for a functionality of the application, an use case. We will do a little of analysis, a little of development, a little of test, a little of demo and one release for this use case. In this case if the user explains to us that there is a problem, we correct only this part of the analysis, the rest is analyzed into the next iteration.

This method has more advantages:

• It is easy to adapt, correct a bad situation
• More regular refactoring of the code
• More regular feed back of the end user
• Show to the end user the advancement of the project
• ...

Definition

A test by definition everyone knows what it is. The most important here is "unit", "unit" for an unit, an unit test is a test which will test an unit of independent code of an other. The test must verify the good working of a method for a specific case.

The unit test is not done by the end user of the project but code that will test the code of the software that you are building. At the first look it seems odd but when you do it one time, you will want to do it always.

 

How to do it

Steps

All steps are a part of the following iteration:

• Decide a method to write
• Create a tests list
• Take a test from the list and implement it
• Check that the test code builds and check that the result of the test is red
• Implement the code (doing refactoring if we are not at the first iteration) which will change the result of the test to green
• Run the test and check that the result of the test is green

Sample

We will decide to write a method to do a division of 2 numbers. In the code we write only the signature of the method and the minimum so the code builds:
public double Divide(int a, int b): 

• I create the following tests list ::
  • To check that the division of the 2 numbers is correct
  • To check that the division by 0 throws the good exception.
    • The tests list must cover at least the documentation of the method that we are writing, it is the contract of the method. It is possible that you add documentation to the method when writing the test.
      
      next delete the automatic created class in this project and add a new Unit Test
       
      The next screen lets you choose different classes, choose the method to test
      The skeleton of the test is now created
      We adapt the code to check that the result of the division of 6 by 2 is well 3 and we run the test to check that it builds and that is red.
      Now we adapt the code so the result is green, we write only the code to make the test become green and no more code, it's important so all the code is tested.
      Now we take the next test and we do the same steps, write the test, checks that it's red, implements the code and now we can also do refactoring and we finally check that the test is green.
       
      

Schema of the itiration