Imported Upstream version 3.6.0

Former-commit-id: da6be194a6b1221998fc28233f2503bd61dd9d14
This commit is contained in:
Jo Shields
2014-08-13 10:39:27 +01:00
commit a575963da9
50588 changed files with 8155799 additions and 0 deletions

165
mcs/class/doc/API-notes Normal file
View File

@@ -0,0 +1,165 @@
Please add your comments to this file about mismatches between the API
documentation and the implementation in the Microsoft or ECMA implementations
of the class libraries.
* Type.GetCustomAttributes(Type, bool)
Documentation does not mention that an ArgumentNullException is
thrown if Type is a null value.
* Rectangle.IsEmpty and RectangleF.IsEmpty
Documentation says "This property returns true if the Width, Height, X,
and Y properties of this RectangleF all have values of zero; otherwise,
false." Reality: returns TRUE if width or height are equal 0.
* Array.CreateInstance (Type, long[] lengths)
Docs say if lengths is null, it will throw an ArgumentNullException,
but actually .NET 1.1 throws a NullReferenceException.
* String Constructor (Char[], Int32, Int32):
String s = new String ((char[])null, 0, 0) throws a null, but the docs
say it shouldn't.
* File.Exists:
File.Exists(null) returns false whenever there is a problem with the
path or permissions. This is a security feature which prevents the
abuse of this method to discover what files might exist on the sytem.
This doc error has been confirmed with MS and should be fixed in
the next version of the docs.
* SocketPermission.IsSubsetOf:
10.11.4.* IsSubsetOf 10.11.*.* returns false --> which is incorrect
* SecurityElement.IsValid* ():
All return incorrect results. E.g. IsValidTag ("&") returns true while
it should be false and IsValidAttributeValue ("1 >= 2") returns false
while this should be true.
* SocketPermission.Union (null):
Doesn't throw an ArgumentNullException.
* System.Net.Cookie.Value:
Spec says property cannot accept the semicolon and comma characters,
yet it does.
* System.Net.Cookie.Domain:
Setting this property has no effect on ToString
* System.Net.Cookie Path:
Setting this property has no effect on ToString
* System.Net.CookieCollection:
The ReadOnly property has a getter only, which always returns true.
Yet you can always add Cookie's.
* Array.IList.Contains(object):
Throws an exception when called on a multi-dimensional array. Docs
do not say this. Similar to Array.IList.IndexOf(object).
* Version.CompareTo(null):
Does not throw an exception. Any version compared to null is
considered to be subsequent to null.
* BitConverter.To*():
The docs say it should be ArgumentOutOfRangeException in the
case where "startIndex is less than zero or greater than the
length of value minus 2.", but the mscorlib throws an
ArgumentException.
* Guid.Guid(string) ctor:
The documentation says this ctor accepts (amongst others) the format
"{0xdddddddd,0xdddd,0xdddd,{0xdd},{0xdd},{0xdd},{0xdd},{0xdd},{0xdd},
{0xdd},{0xdd}}". As implemented in mscorlib, however, it accepts:
"{0xdddddddd,0xdddd,0xdddd,{0xdd,0xdd,0xdd,0xdd,0xdd,0xdd,0xdd,0xdd}.
* Guid.ToString(string format):
The documentation specifies that if the format is the empty
string or null, this is equivalant to a format "N". In
mscorlib, the format "D" is taken here.
* String.Compare (String, Int32, String, Int32, Int32):
The documentation is a bit confusing.
In the "Remarks" section it says
>> The number of characters compared is the lesser of the length of
strA less indexA, the length of strB less indexB, and length.
In the "Exception" section it says a condition for the
ArgumentOutOfRangeException
>> The sum of indexA and length is greater than strA. Length.
>> -or-
>> The sum of indexB and length is greater than strB. Length.
>> -or-
>> indexA, indexB, or length is negative.
The latter implies that Compare ("ab", 0, "abcdef", 0, 3) will
throw an exception - but the "Remarks" section implies that it will
not. Both mscorlib.dll and our class libraries behave according to
the "Remarks" section.
* TypeBuilder.GetInterfaces
This method does not return all the interfaces as documented,
it only returns the interfaces that are implemented by this
class, but not the interfaces that are exposed by the parent
classes
* Array.CopyTo (Array, int).
According to the documentation, an ArgumentException is thrown
if either "index is equal to or larger than the size of the
array" or "the number of elements in the source array is
greater than the available space from index to the end of the
destination array".
The first condition is wrong, an exception is not thrown if
index is equal to the length of array, but the source array
contains zero elements:
int[] src = new int [0];
int[] dest = new int [0];
src.CopyTo (dest, 0)
* Assembly.Load (string)
The documentation states that the argument is the 'display name'
of an assembly (eg 'System.Data') but since v1 this method will
only successfully load an assembly if a full reference is given.
The docs even give the following example:
Assembly SampleAssembly;
// Load the assembly by providing the type name.
SampleAssembly = Assembly.Load("System.Data");
which fails with a FileNotFoundException. Apparently the method
to use for loading an assembly given a display name is
Assembly.LoadWithPartialName (string).
* SortedList.Clear ()
The documentation claims that the Capacity of the sorted list
will not change, but it does.
* StringBuilder.Insert (int index, string value, int count)
It throws an exception for count < 1 instead of count < 0, which
is what ECMA says.

View File

@@ -0,0 +1,110 @@
Mono NUnit Test Guidelines and Best Practices
Authors: Nick Drochak <ndrochak@@gol.com>
Martin Baulig <martin@@gnome.org>
Last Update: 2003-05-11
Rev: 0.5
* Purpose
This document captures all the good ideas people have had about
writing NUnit tests for the mono project. This document will be useful
for anyone who writes or maintains unit tests.
* Other resources
- mcs/class/README has an explanation of the build process and
how it relates to the tests.
- http://nunit.org is the place to find out about NUnit
* Getting Started
If you are new to writing NUnit tests, there is a template you may use
to help get started. The file is:
mcs/class/doc/TemplateTest.cs
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
-- Provide an unique error message for Assertion.Assert ()
Include an unique message for each Assertion.Assert () so that when the assert
fails, it is trivial to locate the failing one. 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.
Bad:
Assertion.AssertEquals ("array match", compare[0], i1[0]);
Assertion.AssertEquals ("array match", compare[1], i1[1]);
Assertion.AssertEquals ("array match", compare[2], i1[2]);
Assertion.AssertEquals ("array match", compare[3], i1[3]);
Good:
Assertion.AssertEquals ("#A01", compare[0], i1[0]);
Assertion.AssertEquals ("#A02", compare[1], i1[1]);
Assertion.AssertEquals ("#A03", compare[2], i1[2]);
Assertion.AssertEquals ("#A04", compare[3], i1[3]);
Once you used such a number in an Assertion.Assert (), don't change it later on -
people might use it it identify the test in bug reports or in mailing
lists.
-- Use Assertion.AssertEquals () to compare things, not Assertion.Assert ().
Never compare two values with Assertion.Assert () - if the test fails, people
have no idea what went wrong while Assertion.AssertEquals () reports the failed
value. Also, make sure the second paramter is the expected value, and the third
parameter is the actual value.
Bad:
Assertion.Assert ("A01", myTicks[0] == t1.Ticks);
Good:
Assertion.AssertEquals ("A01", myTicks[0], t1.Ticks);
-- Namespace
Please keep the namespace within each test directory consistent. Of course
you can use subnamespaces as you like - especially for subdirectories of
your testsuite.
-- Test your test with the microsoft runtime
If possible, try to run your testsuite with the Microsoft runtime 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 list -
we'll forward this to the Microsoft people from time to time to help
them fix their documentation and runtime.

View File

@@ -0,0 +1,65 @@
// this is a template for making NUnit version 2 tests. Text enclosed in curly
// brackets (and the brackets themselves) should be replaced by appropriate
// code.
// {File Name}.cs - NUnit Test Cases for {explain here}
//
// {Author Name} ({Author email Address})
//
// (C) {Copyright holder}
//
// these are the standard namespaces you will need. You may need to add more
// depending on your tests.
using NUnit.Framework;
using System;
// all test namespaces start with "MonoTests." Append the Namespace that
// contains the class you are testing, e.g. MonoTests.System.Collections
namespace MonoTests.{Namespace}
{
// the class name should end with "Test" and start with the name of the class
// you are testing, e.g. CollectionBaseTest
[TestFixture]
public class {Class to be tested}Test : Assertion {
// this method is run before each [Test] method is called. You can put
// variable initialization, etc. here that is common to each test.
// Just leave the method empty if you don't need to use it.
// The name of the method does not matter; the attribute does.
[SetUp]
public void GetReady() {}
// this method is run after each Test* method is called. You can put
// clean-up code, etc. here. Whatever needs to be done after each test.
// Just leave the method empty if you don't need to use it.
// The name of the method does not matter; the attribute does.
[TearDown]
public void Clean() {}
// this is just one of probably many test methods in your test class.
// each test method must be adorned with [Test]. All methods in your class
// adorned with [Test] will be automagically called by the NUnit
// framework.
[Test]
public void {Something} {
// inside here you will exercise your class and then call Assert()
}
// An nice way to test for exceptions the class under test should
// throw is:
/*
[Test]
[ExpectedException(typeof(ArgumentNullException))]
public void OnValid() {
ConcreteCollection myCollection;
myCollection = new ConcreteCollection();
....
AssertEquals ("#UniqueID", expected, actual);
....
Fail ("Message");
}
*/
}