For those who are interested in unit testing and test driven development, they can give it a try on CSC343 A2 using NUnit. People can download it from http://www.nunit.org. Actually this test unit framework allows you to write tests for all languages within Visual Studio .NET. We used this a lot at IntelliGauge for unit testing. We also used NUnitASP for asp.net web testing; you can actually simulate user interaction with asp webpages through this tool. For a quick outline on how to get Nunit up and running with VB, and how to use it, check out http://www.codeguru.com/vb/gen/vb_misc/samples/article.php/c9399/ Perhaps this is something the CCIT labs would like to install (though I don't know how big of a job this is.) I hope people at least give this a try sometime.. it can make their lives a lot easier when it comes to designing large scale applications. Even if people don't plan on using VB past this course, it is still a good place to start since test driven development skills are independent of specific languages; skills they learn now can be applied to a project of any language (assuming there exists a test framework for that language.) This is also especially true since many testing frameworks are based on the popular "Junit" style of testing, so it is very easy to swtich from one framework to another. Also if people seriously want to get into test driven development, another key tool (or methodology) to take advantage of is refactoring. In fact I don't see how you could take full advantage of test driven development without the use of refactoring. http://www.codeproject.com/dotnet/tdd_in_dotnet.asp This page goes into more detail about the approach to take in test driven development. Specifically it outlines the basic steps of the test-writing cycle: 1. Write a test (there should be no code to test yet.) 2. Try to compile the test (compiling should fail since there is not enough underlying code to make it work) 3. Write just enough underlying code to make the test compile (i.e. write empty classes, methods, etc.) 4. Run the test (since the underlying code isn't fully functional) 5. Implement the functionality of the underlying code to make the test pass. 6. Run the test (it should pass.) 7. Start writing a new test. I know from experience that this can be very hard to adopt if you're used to writing code then testing it (if you even test it at all,) but it makes the development of large (and small) applications go much more smoothly. I recommend just giving it a try here and there. This method takes practice, and it may be slow to start off with; but just like anything else, the more you practice it the easier it becomes.