
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

font-size: 10pt;

font-family:Verdana

}

</style>

</head>

<body class='hmmessage'>

And while on the subject, tests invoking the database layer are not unit tests, they are integration tests, and should be run as a separate batch. Unit tests should be FAST so you can run the whole suit on each refactoring without hesitation.<BR><BR>Best regards,<BR>Stefan Andersson<BR>Tribal Media AB<BR><BR><BR><BR> <BR>> Date: Tue, 10 Mar 2009 18:24:56 +0900<BR>> From: mmazur@gmail.com<BR>> To: mmazur@gmail.com<BR>> CC: arthursv@linux.vnet.ibm.com; opensim-dev@lists.berlios.de<BR>> Subject: Re: [Opensim-dev] Unit tests should not be coupled (WAS: Re: [Opensim-commits] r8737 - trunk/OpenSim/Framework/Communications/Tests)<BR>> <BR>> Hi,<BR>> <BR>> On Tue, 10 Mar 2009 17:03:44 +0900<BR>> Mike Mazur <mmazur@gmail.com> wrote:<BR>> <BR>> > I'm pretty sure by using<BR>> > fixtures properly in OpenSim's unit tests, the need for Chained Tests<BR>> > can be eliminated.<BR>> <BR>> I took a look at OpenSim/Data/Tests/BasicGridTest.cs. There are a few<BR>> tests there that depend on the order they're executed in order to<BR>> succeed. By removing the T???_ prefix from the methods, the unit tests<BR>> fail:<BR>> <BR>> Test Case Failures:<BR>> 1) OpenSim.Data.MySQL.Tests.MySQLGridTest.LoadEmpty : Expected: null<BR>> But was: <OpenSim.Data.RegionProfileData><BR>> <BR>> at OpenSim.Data.Tests.BasicGridTest.LoadEmpty () [0x00000]<BR>> at (wrapper managed-to-native)<BR>> System.Reflection.MonoMethod:InternalInvoke<BR>> (object,object[],System.Exception&) at<BR>> System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags<BR>> invokeAttr, System.Reflection.Binder binder, System.Object[]<BR>> parameters, System.Globalization.CultureInfo culture) [0x00000]<BR>> <BR>> 2) OpenSim.Data.MySQL.Tests.MySQLGridTest.RegionList : Expected: 2<BR>> But was: 1<BR>> <BR>> at OpenSim.Data.Tests.BasicGridTest.RegionList () [0x00000]<BR>> at (wrapper managed-to-native)<BR>> System.Reflection.MonoMethod:InternalInvoke<BR>> (object,object[],System.Exception&) at<BR>> System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags<BR>> invokeAttr, System.Reflection.Binder binder, System.Object[]<BR>> parameters, System.Globalization.CultureInfo culture) [0x00000]<BR>> <BR>> This is expected. So I refactored those tests a little in order to get<BR>> rid of this dependency. I'm attaching the result to this email; look at<BR>> this email in the archives[1] to download the attachment.<BR>> <BR>> Here's a summary of the changes:<BR>> <BR>> - SimpleAddRetrieveProfile() test can be removed, as<BR>> AddRetrieveCompleteTest() tests the same code<BR>> - RandomName() looks like a utility function and doesn't have any<BR>> asserts, so it doesn't need the [Test] attribute<BR>> - extracted the region adding code in AddRetrieveCompleteTest() into a<BR>> method called createRegion(UUID, string) which creates a region in<BR>> the database; this method is called from any test that needs a region<BR>> to exist in the DB<BR>> - added a [TearDown] method, which is called after every test has been<BR>> executed by the NUnit framework, which removes all the regions from<BR>> the DB<BR>> <BR>> If nobody has any strong objections to this approach to isolating<BR>> tests, I'll commit this tomorrow. Also, it's probably a good idea to<BR>> refactor other tests in a similar fashion. If chaining tests is not<BR>> absolutely necessary, it shouldn't be done.<BR>> <BR>> One more thing to note, those tests use GridDataBase.AddProfile() to add<BR>> regions to the DB and GridDataBase.GetProfile*() to get the region back.<BR>> This is flawed; imagine the GridDataBase implementation had a bug that<BR>> prevented anything from actually being stored to disk. Its caching<BR>> mechanism worked as expected, though, and anything that was added with<BR>> AddProfile() was always available with GetProfile*() as long as the<BR>> application (grid server) was running. The functionality of actually<BR>> reading the disk/DB was never actually tested.<BR>> <BR>> To ensure the correct functionality is being tested, one would insert<BR>> the data into the DB by different means (possibly SQL statements in the<BR>> tests), then retrieve them using the proper GetProfile*() method.<BR>> <BR>> Thanks,<BR>> Mike<BR>> <BR>> <BR>> [1]<BR>> https://lists.berlios.de/pipermail/opensim-dev/2009-March/thread.html<BR></body>

</html>