+ In some classes, we might also provide standalone tests because of
+ some reasons such as too huge testcases, another downloading and so on.
+ (For example, managed XSLT has standalone test which downloads and
+ expands some megabytes of OASIS test suite.)
+
+ Here I list them up as long as I know. If you are going to add another
+ standalone tests, please add one line here. It is also recommended that
+ you add some notes on how to build and run tests.
+
+ <ul>
+
+ * Mono.Data/test/
+ * System.Data/Test, and some individual ADO.NET libraries:
+ there are some standalone tests. See the bottom of <a href="ado-net.html">
+ ADO.NET page</a> for detail.
+ * System.Web/Test/TestMonoWeb : see README
+ * System.Web.Services/Test/standalone : see README
+ * System.Windows.Forms/SWFTest/
+ * System.XML/Test/System.Xml/standalone_tests : see README
+ * System.XML/Test/System.Xml.Schema/standalone_tests : see README
+ * System.XML/System.Xml.Serialization/standalone_tests/
+ * System.XML/Test/System.Xml.Xsl/standalone_tests : see README
+ * Commons.Xml.Relaxng/Test/standalone_tests : see README
+
+ </ul>
+
+** 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 needs also to be listed in the
+ .sources file at the top of the Test directory.
+
+* 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.html">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.