NetTiers unit testing

Lately I've been looking at the unit tests being generated for NetTiers a quite common case for me is the following failure

Step_01_Insert : System.Data.SqlClient.SqlException : The INSERT statement conflicted with the FOREIGN KEY constraint ...

So I'm a bit curious how do you actually go about doing unit testing? Do you pre-fill the database with information based on the unit tests generated to allow them to pass successfully or do you tweak the generated code (alas it get overwritten each time you regenerate the NetTiers solution)?

I’m using VS2005 to do the unit testing instead of NUnit and VS2005 likes to set attributes on the methods being test cases to control such things as whether the test is enabled or not, timeout etc. What annoys me today is that all that tweaking of individual test cases is lost when the NetTiers solution is regenerated. What I’m been thinking about is to use partial classes to split the unit tests into

 

XXXTest.cs that is never overwritten and an XXXTest.generated.cs that is always overwritten.

 

The XXXTest.cs would be generated with attributed methods as today

 

From XXXTest.cs

[TestMethod]

public void Step_01_Insert()

{

           // TODO: Establish necessary preconditions here

           Step_01_Insert_generated();

           // TODO: Provide additional verification here
}

From XXXTest.generated.cs

public void Step_01_Insert_generated()

{

   Assert.IsTrue(DataRepository.AreaProvider.Insert(transactionManager, mock), "Insert failed");
   System.Console.WriteLine("DataRepository.AreaProvider.Insert(mock):");                           

   System.Console.WriteLine(mock);                      

}

 

Comments, suggestions? Anyone else interested?

That's an excellent suggestion for the unit tests! 

As far as the inserts concerned, it does so in the context of a transaction, so that on TearDown the transaction is rolled back.  I can see though, situations where that might be invasive.  Perhaps we should look into using a provider stub.

I have seen the generated unit tests have problems when testing an insert of an item which has a non-nullable foreign key reference to another table that does not have any data.  This would be a common scenario on a new project with a completely empty database.  The actual problem lies within the CreateMockInstance() method.  For example:

Products mock = new Products();
TList<Categories> _collection0 = DataRepository.CategoriesProvider.GetAll(transactionManager, 0, 10);
if (_collection0.Count > 0)
{
    mock.CategoryID = _collection0[0].CategoryID;
}

If CategoryID is required but there are no records in the Categories table, the insert would fail.  I have always felt that unit tests should not assume anything and that they should provide any data that they may need.  Following that principle, the ProductsTest class would need to insert records into the Categories table, which would not get persisted due to the transaction being rolled back.

Regards,
Bobby

Now that sounds sensible to me. That would be possible to accomplish. In the modification of the unit tests I did to make them run in VS2005 I made the CreateMockInstance() method static. Make it static and public and then it is usable to create whatever is needed in those other unit tests. I’ll put it on the TODO list. I need to think a bit more about it. There might be a risk running into loops (the same issue as with deep loading) if you are not careful.

 

There are more issues with the unit tests. Today they depend on each other, the typical example being Step_04_Update depending on Step_01_Insert, so if update fails it is not enough to re-run that step alone you have to run the insert as well in order to keep the update step happy. This could be improved to make each step self contained.

 

By the way, do you have any preferred way to make code contributions? Patch files, whole versions or what? Today I zip my modified NetTiers2 and put it under the contributions forum for people to download if they are interested.

Yes, another team member was mentioning that the tests are not atomic.  Which I probably agree, each tests should run independantly of one another, and should not require any previous methods in order to run.

About submissions, I think both, patch with modified templates or template set.  That way we can go back to the applied branch of when it took place if we had to.

Also when contributing, ensure to get latest template version before making your changes.   That way it minimizes the chance for merge conflicts.