X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=web%2Ftesting;h=f86968cc4dbadb0e6266f2ee2d6e33fb536ef57c;hb=9d93ddc5daf9a96e7fcd5d9ef7fac0ddba68feb9;hp=82be11d0559cb707a4a70c413dbbd7d8ac66ccdf;hpb=4b5634d553286ea6534580e4153bd1a8b5a22682;p=mono.git

diff --git a/web/testing b/web/testing
index 82be11d0559..f86968cc4db 100644
--- a/web/testing
+++ b/web/testing
@@ -9,13 +9,114 @@
 ** Class Library Tests
 
 	All classes in Mono libraries should have comprehensive unit test
-	suites to go with them. Unit testing is a software engineering
-  	methodology that makes it easier to build correct code. Every
+	suites to go with them.  Unit testing is a software engineering
+  	methodology that makes it easier to build correct code.  Every
   	method in every class should have a set of tests to verify
-  	that they work correctly. Mono also needs a testing framework
+  	that they work correctly.  Mono also needs a testing framework
 	to make it easy to write and run lots of tests. 
 
-	Try <a href="http://nunit.sourceforge.net">NUnit</a>
+
+** Getting started
+
+	If you are new to writing NUnit tests, there is a template you may use
+	to help get started. The file is:
+
+		<b>mcs/class/doc/TemplateTest.cs</b>
+
+	Save a copy of this file in the appropriate test subdirecty
+	(see below), and replace all the {text} markers with
+	appropriate code. Comments in the template are there to guide
+	you. You should also look at existing tests to see how other
+	people have written them.
+	mcs/class/corlib/Test/System.Collections/CollectionBaseTest.cs
+	is a small one that might help.
+
+	The directory that will contain your new file depends on the
+	assembly/namespace of the class for which you are creating the
+	tests.  Under mcs/class there is a directory for each
+	assembly. In each assembly there is a Test directory,
+	e.g. mcs/class/corlib/Test. In the Test directory there are
+	sub-directories for each namespace in the assembly,
+	e.g. mcs/class/corlib/Test/Sytem. Put your new test file in
+	the appropriate sub-directory under Test for the class you are
+	testing.
+	
+	Once all of that is done, you can do a 'make test' from the top mcs
+	directory.  Your test class will be automagically included in the
+	build and the tests will be run along with all the others.
+
+* Tips on writing Unit tests.
+
+	You should look at the <a href="http://nunit.org">NUnit documentation</a>,
+	as it is a fantastic product, and includes fantastic documentation,
+	but here are some tips for those of you who are already reading
+	this web page.
+
+
+** Provide an unique error message for Assert()
+
+	Include an unique message for each Assert() so that when the assert
+	fails, it is trivial to locate it in the source. Otherwise, it may be
+	difficult to determine which part of the test is failing. A good way
+	to ensure unique messages is to use something like #A01, #A02 etc.
+
+	    Ok:
+	<pre>
+	
+		AssertEquals("array match", compare[0], i1[0]);
+		AssertEquals("array match", compare[1], i1[1]);
+		AssertEquals("array match", compare[2], i1[2]);
+		AssertEquals("array match", compare[3], i1[3]);
+	</pre>
+
+	    Excellent:
+	<pre>
+		AssertEquals("#A01", compare[0], i1[0]);
+		AssertEquals("#A02", compare[1], i1[1]);
+		AssertEquals("#A03", compare[2], i1[2]);
+		AssertEquals("#A04", compare[3], i1[3]);
+	</pre>
+	
+	Once you used such a number in an Assert(), don't change it later on -
+	people might use it it identify the test in bug reports or in mailing
+	lists.
+
+** Use AssertEquals() to compare things, not Assert().
+
+	Do not compare two values with Assert() - if the test fails,
+	people have no idea what went wrong while AssertEquals()
+	reports the failed value.
+
+	Ok:
+	<pre>
+	        Assert ("A01", myTicks[0] == t1.Ticks);
+	</pre>
+
+	Excellent:
+	<pre>
+	        AssertEquals ("A01", myTicks[0], t1.Ticks);
+	</pre>
+
+** Test your test with the Microsoft runtime
+	
+	If possible, try to run your testsuite with the Microsoft runtime on
+	.NET on Windows and make sure all tests in it pass. This is especially
+	important if you're writing a totally new testcase - without this
+	check you can never be sure that your testcase contains no bugs ....
+	
+	Don't worry if you're writing your test on Linux, other people can
+	test it for you on Windows.
+	
+	Sometimes you may discover that a test doesn't show the expected
+	result when run with the Microsoft runtime - either because there is a
+	bug in their runtime or something is misleading or wrong in their
+	documentation. In this case, please put a detailed description of the
+	problem to mcs/class/doc/API-notes and do also report it to the 
+	<a href="mailing-lists">mailing list</a> - we'll forward this to the
+	Microsoft people from time to time to help them fix their documentation
+	and runtime.
+
+** Unit tests.
 
 	Why do unit testing? It becomes simple to run automated tests
 	for the whole library. Unit tests are a safety net - you can
@@ -29,3 +130,18 @@
 	JUnit Test Infected: Programmers Love Writing Tests</a>.
 
 
+** Getting Started
+
+	We welcome all contributions to the Class Libary Test Suite.
+
+	There is information to help you get started in CVS at
+	mcs/class/doc/NUnitGuidelines. Once you have written your test, please
+	post it to <a href="mailing-lists.html">mono-list</a>.
+
+	Someone will make sure to add the file or apply the patch as
+	appropriate. If you plan to be an on-going contributor and
+	would like to get cvs account, email <a href="mailto:miguel@ximian.com">miguel</a>.
+
+	Normally, after you send a couple of well-written new files
+	and/or patches to the list, you will be given cvs access.
+