However, you are not limited to the set of tools listed here. But tools are not silver bullets! Knowing all the tools here does not mean that your productivity will increase or your project will be a success. It depends on how well you integrate them into your development work. For example, how should you partition your code into packages, which directory to place documentation, who does the integration, how to resolve bugs during system testing etc. These are things tools can't help you with. Hence, if you want to maximize the potential of the tools, you need to integrate them into your work in such a way that it flows with your team's dynamics.
Below are a few short guides we wrote on how to use the tools. Note that they are not substitute for the documentation that comes with the tools. They are meant to help you get started and thus will not cover everything.
Your collection of test cases should grow with the functionality you implement. ( indeed, some advocates 'test first development' where test are written before the program!). Remember, unit testing goes at least in parallel with development, certainly NOT at the end of the project.
It's not unusual for your test code to be more than 50% of the total amount of code - and it's worth every bit of effort. You may feel too lazy to write test cases at first, but once you are test-infected, it makes programming so much more fun, and way less frustrating. All that effort of writing test cases will help you excel towards the end, when you need to do changes to the code base that has beocme large and complex over time.
NUnit is a free and open source unit testing tool for C# developers. It integrates well with VisualStudio.NET and relatively well documented. Here's a short guide to get you started with csUnit. For more info, go to http://www.nunit.org.
If you are not happy with nUnit, csUnit is another similar unit testing tool for .Net languages. Visit http://www.csunit.org for more info.
From a tools perspective, integration testing is not much different from unit testing. You can use the tools given above.
As you'll discover, unit testing does not replace the need for assertions. Keep using assertions (provided by C#) where they make sense. Assertions and unit testing serve two different purposes.
As your team progresses into the project, you all will be creating more and more source code. As each of you are working independently on different parts of the system, you will occasionally need to pass your set of codes to other members for integration. During integration, a bug may be uncovered in your code. So, you make a change and send the code out again to the rest of your members. A new one may then be discovered and the cycle continues. In the end, each member ends up with so many versions you don't know which is the latest one.
Well, that's where SVN comes in. SVN stands for Subversion. The strength of SVN comes from the fact that it is able to provide record keeping (i.e. revision control) as well as facilitate collaboration. Many of the current open source projects (consisting of hundreds of developers) use SVN. SVN is not a difficult tool to use. Furthermore, there are many good documentation available.
Each group has been assigned a repository at https://subversion.comp.nus.edu.sg/svn/cs3215/group<no>. A repository is simply a central location where files shared among group members will be mounted. However, different from the standard file sharing, the repository also track changes that have been made to the shared files. The repository will serve as the SVN server. Simply login with your SOC UNIX ID. One can also browse the repository content by accessing the above URL through their favorite web browser.
A short guide to get you started with using SVN from windows can be found here. The guide is just to give you a head start by introducing you to some basic usage of SVN. You are expected to refer to the documentation listed in the references to enhance your usage of the SVN. You can also visit the SVN website for more info.
Let's face it, not even the best programmers will get everything right the first time. As the work progresses, you will realize many things that could have improved the system, if only you realized them earlier. To give a simple example, you might realize that a certain method name is no longer reflects what the method does, leading to confusion among the users of that method. Ideally, you should change the name right away to a better name. Doing such changes is called Refactoring. More formally...
"Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." (more...)
In most such cases, you will hesitate to refactor, because of the additional workload (have to modify many places in the code) and the risk (of breaking something while modifying the code) involved.
To ease the workload of refactoring, there are automated refactoring tools. For example, you can select a method and say 'change name from foo to bar' and the modification will be carried out automatically, including in all places where the method is used. Changing method name is just one of the many refactorings such tools can help you with. VS.Net 2005 comes with built-in refactoring tool - it can be accessed from the `Refactor' menu bar or right clicking the desired code to refactor from within VS.Net IDE.
For a reference, please refer to:
To reduce the risk involved in refactoring, you should refactor in small steps and run unit tests after each refactoring. The better your suite of unit tests is, the bolder you can be in refactoring. If things got messed up, you can always use SVN to revert to an earlier version.
An alternative is Microsoft Visio, that is downloadable from the workshop at https://mysoc.nus.edu.sg/~agreemt/agree.php