Need help using VS 2008 Unit Test framework.

[Tom P.]

I am trying to use the VS 2008 Unit Test framework to test an
application and I'm running into a problem. I have an object that has
a protected method that sets a public field. The problem is, the auto-
generated ???_Accessor doesn't expose the public fields or methods. It
only exposes the internal fields. So how do I get access to the public
AND internal fields using the BaseShadow (or some derived) class?

Thanks,

Tom P.

 

[Gregory A. Beamer]

I am trying to use the VS 2008 Unit Test framework to test an
application and I'm running into a problem. I have an object that has
a protected method that sets a public field. The problem is, the auto-
generated ???_Accessor doesn't expose the public fields or methods. It
only exposes the internal fields. So how do I get access to the public
AND internal fields using the BaseShadow (or some derived) class?

It should have created an accessor that has this. Perhaps you added the
bits after you originally created. I just ran a test to ensure I was
correct. Here is my simple class:

public class Class1
{
public string Value { get; private set; }

public Class1()
{
SetPublicMember("Testing");
}

protected void SetPublicMember(string value)
{
Value = value;
}
}

I then gened a Unit Test, which is this:


[TestMethod()]
[DeploymentItem("GBWorld.UnitTesting.Business.dll")]
public void SetPublicMemberTest()
{
Class1_Accessor target = new Class1_Accessor(); // TODO: Initialize
to an appropriate value
string value = "Testing 2"; // TODO: Initialize to an appropriate
value
target.SetPublicMember(value);

Assert.AreEqual(value, target.Value, "Value does not equal 'testing
2'.");
}

And here is the accessor class:

[Shadowing("GBWorld.UnitTesting.Business.Class1")]
public class Class1_Accessor : BaseShadow
{
protected static PrivateType m_privateType;

[Shadowing(".ctor@0")]
public Class1_Accessor();
public Class1_Accessor(PrivateObject __p1);

public static PrivateType ShadowedType { get; }
[Shadowing("Value")]
public string Value { get; set; }

public static Class1_Accessor AttachShadow(object __p1);
[Shadowing("SetPublicMember@1")]
public void SetPublicMember(string value);
}

Hopefully this helps.

Peace and Grace,



--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[Tom P.]

I am trying to use the VS 2008 Unit Test framework to test an
application and I'm running into a problem. I have an object that has
a protected method that sets a public field. The problem is, the auto-
generated ???_Accessor doesn't expose the public fields or methods. It
only exposes the internal fields. So how do I get access to the public
AND internal fields using the BaseShadow (or some derived) class?

It should have created an accessor that has this. Perhaps you added the
bits after you originally created. I just ran a test to ensure I was
correct. Here is my simple class:

    public class Class1
    {
        public string Value { get; private set; }

        public Class1()
        {
            SetPublicMember("Testing");
        }

        protected void SetPublicMember(string value)
        {
            Value = value;
        }
    }

I then gened a Unit Test, which is this:

[TestMethod()]
[DeploymentItem("GBWorld.UnitTesting.Business.dll")]
public void SetPublicMemberTest()
{
    Class1_Accessor target = new Class1_Accessor(); // TODO: Initialize
to an appropriate value
    string value = "Testing 2"; // TODO: Initialize to an appropriate
value
    target.SetPublicMember(value);

    Assert.AreEqual(value, target.Value, "Value does not equal 'testing
2'.");

}

And here is the accessor class:

    [Shadowing("GBWorld.UnitTesting.Business.Class1")]
    public class Class1_Accessor : BaseShadow
    {
        protected static PrivateType m_privateType;

        [Shadowing(".ctor@0")]
        public Class1_Accessor();
        public Class1_Accessor(PrivateObject __p1);

        public static PrivateType ShadowedType { get; }
        [Shadowing("Value")]
        public string Value { get; set; }

        public static Class1_Accessor AttachShadow(object __p1);
        [Shadowing("SetPublicMember@1")]
        public void SetPublicMember(string value);
    }

Hopefully this helps.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog:http://gregorybeamer.spaces.live.com

*******************************************
|      Think outside the box!             |
*******************************************

Thank you very much for that. I knew it was possible.

It also pointed out a more insidious problem I'm going to have... I am
inheriting from the ListView class but there is a public property of
that inherited class that is not showing up. I'll dig a little more
and see what I can come up with specifically.

Thanks for the help.
Tom P.

 

[Tom P.]

I am trying to use the VS 2008 Unit Test framework to test an
application and I'm running into a problem. I have an object that has
a protected method that sets a public field. The problem is, the auto-
generated ???_Accessor doesn't expose the public fields or methods. It
only exposes the internal fields. So how do I get access to the public
AND internal fields using the BaseShadow (or some derived) class?

It should have created an accessor that has this. Perhaps you added the
bits after you originally created. I just ran a test to ensure I was
correct. Here is my simple class:

    public class Class1
    {
        public string Value { get; private set; }

        public Class1()
        {
            SetPublicMember("Testing");
        }

        protected void SetPublicMember(string value)
        {
            Value = value;
        }
    }

I then gened a Unit Test, which is this:

[TestMethod()]
[DeploymentItem("GBWorld.UnitTesting.Business.dll")]
public void SetPublicMemberTest()
{
    Class1_Accessor target = new Class1_Accessor(); // TODO: Initialize
to an appropriate value
    string value = "Testing 2"; // TODO: Initialize to an appropriate
value
    target.SetPublicMember(value);

    Assert.AreEqual(value, target.Value, "Value does not equal 'testing
2'.");

}

And here is the accessor class:

    [Shadowing("GBWorld.UnitTesting.Business.Class1")]
    public class Class1_Accessor : BaseShadow
    {
        protected static PrivateType m_privateType;

        [Shadowing(".ctor@0")]
        public Class1_Accessor();
        public Class1_Accessor(PrivateObject __p1);

        public static PrivateType ShadowedType { get; }
        [Shadowing("Value")]
        public string Value { get; set; }

        public static Class1_Accessor AttachShadow(object __p1);
        [Shadowing("SetPublicMember@1")]
        public void SetPublicMember(string value);
    }

Hopefully this helps.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog:http://gregorybeamer.spaces.live.com

*******************************************
|      Think outside the box!             |
*******************************************

Huh? For some bizarre reason Unit Test Accessors stop at framework
objects.

If I inherit from a custom object the inherited fields and methods get
"shadowed" properly. But, if I inherit from TextBox none of the
properties or methods come accross. In fact if you inherit from
TextBox and only add protected or private fields the wizard won't even
allow the generation of a Test Class.

I wonder if I can create a custom Accessor and allow it to access the
fields and properties I need.

Tom P.

 

[Tom P.]

(e-mail address removed):

It should have created an accessor that has this. Perhaps you added the
bits after you originally created. I just ran a test to ensure I was
correct. Here is my simple class:

    public class Class1
    {
        public string Value { get; private set; }

        public Class1()
        {
            SetPublicMember("Testing");
        }

        protected void SetPublicMember(string value)
        {
            Value = value;
        }
    }

I then gened a Unit Test, which is this:

[TestMethod()]
[DeploymentItem("GBWorld.UnitTesting.Business.dll")]
public void SetPublicMemberTest()
{
    Class1_Accessor target = new Class1_Accessor(); // TODO: Initialize
to an appropriate value
    string value = "Testing 2"; // TODO: Initialize to an appropriate
value
    target.SetPublicMember(value);

    Assert.AreEqual(value, target.Value, "Value does not equal 'testing
2'.");
}

And here is the accessor class:

    [Shadowing("GBWorld.UnitTesting.Business.Class1")]
    public class Class1_Accessor : BaseShadow
    {
        protected static PrivateType m_privateType;

        [Shadowing(".ctor@0")]
        public Class1_Accessor();
        public Class1_Accessor(PrivateObject __p1);

        public static PrivateType ShadowedType { get; }
        [Shadowing("Value")]
        public string Value { get; set; }

        public static Class1_Accessor AttachShadow(object __p1);
        [Shadowing("SetPublicMember@1")]
        public void SetPublicMember(string value);
    }

Not using that test harness, that is what I basically told the op to do
in another post was to use a public class/function to access a protected
method or property.

Sorry, but George has shown that what I was asking is indeed possible,
it so happens that my problem is related to the Unit Test Generator,
not the framework as you keep insisting.

Thank you for continuing to insist on an unhelpful and, indeed,
unwanted course of action. I thought I had made clear that the
suggestions you are offering are not what I am looking for. I know you
are trying to help but I am looking in a different direction than the
one you continue to insist is the only way.

I get it. You want me to use Mock objects. I get it.

Thank you for your input.

Tom P.

 

[Gregory A. Beamer]

(e-mail address removed):

If I inherit from a custom object the inherited fields and methods get
"shadowed" properly. But, if I inherit from TextBox none of the
properties or methods come accross. In fact if you inherit from
TextBox and only add protected or private fields the wizard won't even
allow the generation of a Test Class.

My example did not approach an inheritance tree, so you might have to look
at the accessor in the example and attempt to wire up the public property
on the inherited class.

Worst case is overriding and calling to/from the base implementation, so
testing will work. You can set up the override with a conditional region
for debug only if you don't want it in the public bits. It is a bit kludgy,
of course, and the override does not hurt. Then you definitely can shadow
and it will likely be built for you.

My one question here is what are you testing, as it sounds like you are
confirming a unit with a property. That is fine. But if you are running two
bits of code to get to the answer, then you are stepping outside of the
unit and doing something that is more of an implementation test. I am not
personally against using the "unit test framework" for implementation
tests, but they should be in their own test assembly.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[Tom P.]

My example did not approach an inheritance tree, so you might have to look
at the accessor in the example and attempt to wire up the public property
on the inherited class.

Worst case is overriding and calling to/from the base implementation, so
testing will work. You can set up the override with a conditional region
for debug only if you don't want it in the public bits. It is a bit kludgy,
of course, and the override does not hurt. Then you definitely can shadow
and it will likely be built for you.

I think this is what I will have to do. I can only assume that the
test framework stops at NET framework objects because we can't fix
them anyway.

I'll have to do some sort of #if DEBUG to wrap the public properties
for testing.

My one question here is what are you testing, as it sounds like you are
confirming a unit with a property. That is fine. But if you are running two
bits of code to get to the answer, then you are stepping outside of the
unit and doing something that is more of an implementation test. I am not
personally against using the "unit test framework" for implementation
tests, but they should be in their own test assembly.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog:http://gregorybeamer.spaces.live.com

*******************************************
|      Think outside the box!             |
*******************************************

I am testing a custom object that encapsulates the DirectoryInfo
object and provides some better access. The method I'm testing is
SetDirectoryInfo which takes a DirectoryInfo object and a Boolean that
indicates if the directory is a "DotDot" (is this DirectoryItem
actually a pointer for the parent directory for navigation purposes).

The only real difference in the directory object is the text that gets
displayed, and that's what I'm trying to access to see if that got
set.

I was under the impression that checking the workings of a method was
unit testing. Am I mistaken in this? Is there a better way to test
this?

Tom P.

 

[Gregory A. Beamer]

I was under the impression that checking the workings of a method was
unit testing. Am I mistaken in this? Is there a better way to test
this?

A unit test only tests the code in a particular method. As soon as you
confirm outside the unit, you are entering some type of functional
testing. The same is true when you hit a database, the file system, or
other external bits. Sometimes this is a clear indication of a need for
refactoring.

If you are actually hitting the file system in your test, then you are
no longer unit testing. At this point, you are more functional in
nature, perhaps even into some integration testing. There is nothing
wrong with these types of tests, per se, and I often code these types of
tests using the testing framework, but I put them into other assemblies,
as they are not unit tests.

In fact, you will see my assemblies like this:

{company}.{product}.Business
{company}.{product}.Business.Tests.Unit.VS
{company}.{product}.Business.Tests.Unit.MBUnit
{company}.{product}.Business.Tests.Unit.NUnit
{company}.{product}.Business.Tests.Integration.VS

etc.

I want to ensure the longer running tests (non-unit) do not slow down
unit testing.

To get around areas you cannot unit test, you can often use mocks with
IoC or Dependency Injection. I would have to think through the object
inherited from a file system object, however. It may only be tested
through integration tests, but this is not a huge deal as you are
dealing with a utility class. You can, however, refactor the class so
there are testable methods. A method that tests DotDot, for example, is
one you can refactor out and test with a unit testing framework. Whether
refactoring out this method is wise or not will depend on your
application and perhaps if there is an acceptable interface you can code
against for a mock.

Please note that I am not saying you should not test using VS tests
against hte file system. Just don't mix these tests with your other unit
tests.

NOTE: Any time you set up a test against outside bits, you should create
and destroy the outside bits. To do this, create the directory you want
to test in creation method of your test class and then destroy it when
you are spinning it down. If you do not do this, a test can fail if your
system setup changes. Not a problem today, as you will see "oh, the
directory is gone", but it could cause problems later. This won't make
the test a unit test, but it will make it predictable. If you want to be
really safe, you can code in an exception when the directory already
exists:

if(Directory.Exists(dirName))
{
throw new DirExistsException(string.Format("the directory {0}
exists", dirName));
}
else
{
//Create directory
}

This ensures that you do not delete the directory later on if it already
exists.

If you create directories like:

AppName.TestDirectory

And then create a pointer (dotdot) with a similar name, pointing to the
same.

You can then be fairly sure the directory and pointer don't exist. But
it is still safer to test and fail the test(s) than to delete something
that already exists. Even if it turns out to be an error that someone
manually created, you can manually delete and then rerun to confirm the
test.

I hope all of this makes sense. TDD, unit testing, etc. are a paradigm
shift in thinking and take some time, so don't get overly concerned if
it takes a bit of time to get your head around it completely.


Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[Gregory A. Beamer]

A test is not a unit test if:

It talks to the database
It communicates across the network
It touches the file system
It can't run at the same time as any of your other unit tests
You have to do special things to your environment (such as editing
config files) to run it.

Let me add

It has to run in a certain order

This is very similar to (run at same time), but I have seen far too many
people rely on VS's ordering of the tests. rebuild the test runner bits and
you are hosed. ;-)

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[Mr. Arnold]

A unit test only tests the code in a particular method. As soon as you
confirm outside the unit, you are entering some type of functional
testing. The same is true when you hit a database, the file system, or
other external bits. Sometimes this is a clear indication of a need for
refactoring.

YES! And if you have to do special things to an object like running code to
manipulate things to past the test that would not be there normally, then
that's functional testing not unit testing.

You mock it all, like you mock the object or objects, you mock calling the
method to be tested, and if the method calls something else, you don't call
it. You don't go past the first level.

You only go one level deep. One has the assume in unit testing that anything
coming back other than one level deep should not be tested with a unit test
and is assumed to be correct. One has to count on it being correct. However,
if one does need to go past one lavel like calling a Web service or DAL to
get and object back that level on method is returning, then you mock the
call to it to return the mocked object from it based on its interface.

All one wants to test is the interface, the method to be called based on an
object and/or prams passed on the interface to the method, and results
expected back. If an object is to be retuned or going to be sent to the
method, then you mock it, you mock the Directory object testing for the
Directory object being retuned, based on the interface and the call.

There is nothing in the object. I am calling public DTOCandy
TestArnold(DTOArnold, 2). The contract or signature on the method is
DTOCandy TestArnold(DTOArnold, int32).

I give the method what it wants. That's what I am sending it. This is what I
expect back. Did it pass the test? Is everything ok?

One starts doing more than that, it's not unit testing.




__________ Information from ESET NOD32 Antivirus, version of virus signature database 4545 (20091026) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Tom P.]

A unit test only tests the code in a particular method. As soon as you
confirm outside the unit, you are entering some type of functional
testing.  The same is true when you hit a database, the file system, or
other external bits. Sometimes this is a clear indication of a need for
refactoring.

I know that. The questions were a failed attempt at saving face.

I appreciate the pointers but none of this make the framework expose
the public properties of a .NET class.

Nothing I need to do has anything to do with accessing the file system
or a database (the class does but the TEST does not). I realize that
if you leave the unit it's not a unit test. This was the same issue
that got the other thread hung up, and I eventually had to abandon it
and try again. The problem I am having has nothing to do with my
ability to distinguish a unit test from a functional, integration,
limit, boundary, or any other type of test.

It's a simple case of exposing public inherited properties and
protected method calls. The same thing would happen in any inheritable
class in the .NET framework. Or do I just never test that, when a
boolean flag gets passed in to a protected method, the Text property
of that class gets set appropriately? Or are you trying to say that
because it sets the Text property of the base class it's confirming
outside the unit? That seems completely unrealistic to me. If that
were the case you'd have a thousand method calls all with three lines
in them and no way to test anything. You'd ruin any usefulness
inheritance has.


Is it acceptable to inherit from the .NET framework classes?


Is it acceptable to unit test a protected method?


Is it acceptable to assert success against a public property?



That's all I'm trying to do. You guys are so busy trying to tell me
how to separate my tests properly that you've lost track of the actual
question: Can I assert the public properties of a framework class in a
protected method of an inherited class? Or is this a bug in the Test
Wizard?

Tom P.

 

[Tom P.]

YES! And if you have to do special things to an object like running code to
manipulate things to past the test that would not be there normally, then
that's functional testing not unit testing.

You mock it all, like you mock the object or objects, you mock calling the
method to be tested, and if the method calls something else, you don't call
it. You don't go past the first level.

You only go one level deep. One has the assume in unit testing that anything
coming back other than one level deep should not be tested with a unit test
and is assumed to be correct. One has to count on it being correct. However,
if one does need to go past one lavel like calling a Web service or DAL to
get and object back that level on method is returning, then you mock the
call to it to return the mocked object from it based on its interface.

All one wants to test is the interface,  the method to be called based on an
object and/or prams passed on the interface to the method, and results
expected back. If an object is to be retuned or going to be sent to the
method, then you mock it, you mock the Directory object testing for the
Directory object being retuned, based on the interface and the call.

There is nothing in the object. I am calling  public DTOCandy
TestArnold(DTOArnold, 2). The contract or signature on the method is
DTOCandy TestArnold(DTOArnold, int32).

I give the method what it wants. That's what I am sending it. This is what I
expect back. Did it pass the test? Is everything ok?

One starts doing more than that,  it's not unit testing.

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4545 (20091026) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

You are still describing things I'M NOT ASKING.

None of this has anything to do with the question I am posing. I am
not getting anything from any where. I am not making calls to the
filesystem nor am I getting things from the filesystem. There is no
database in anything I am doing.

It's simple, really. Here's the basics of the code:


public class DirectoryListItem : ListViewItem
{
DirectoryInfo _currentDirectory;

protected void SetDirectory(string path, bool IsDotDot)
{
..check to make sure the path is real...
_currentDirectoryInfo = new DirectoryInfo(path);

if(IsDotDot)
{
this.Text = "..";
}
}
}

Now, should the Text property (inherited from ListViewItem) be exposed
in the DirectoryListItem_Accessor? Even if I weren't creating the
DirectoryInfo object I'd still have the same issue.

Tom P.

 

[Mr. Arnold]

It's simple, really. Here's the basics of the code:



public class DirectoryListItem : ListViewItem
{
DirectoryInfo _currentDirectory;

protected void SetDirectory(string path, bool IsDotDot)
{
..check to make sure the path is real...
_currentDirectoryInfo = new DirectoryInfo(path);

if(IsDotDot)
{
this.Text = "..";
}
}
}

Now, should the Text property (inherited from ListViewItem) be exposed
in the DirectoryListItem_Accessor? Even if I weren't creating the
DirectoryInfo object I'd still have the same issue.



--------------------------------------------------

#1 I was posting to you?

#2 You're not even doing a unit test. You are doing a functional test. By
accessing the filesystem which is what you're doing is a functional test.

#3 So why not run it in debug mode right from the UI and get your results to
verify that things are working, which is a functional test too?

#4 I wouldn't waste the time of day on what you're doing with a test-harness
here. It's pointless with you trying to use a test harness to test it.

#5 Unit testing is about simulation and the expect results of the simulation
using a test harness.

Myself, I would use that VS test-harness you're using, set reference to the
Rhino Mock dll and do simulated unit testing with the test harness, doing
unit testing.

Now if I was going to do a functional test, then it would be against a Web
service or a DAL accessing a database things of that nature where I am
testing functionality on the other end, in debug mode if necessary for
expected results.

If I wanted to test UI controls, then a Presenter, a view, and an Interface
would be used, injecting the view into the presenter and testing the
presenter with a functional test or doing the same as a unit test for
expected results.

The problem here is you don't like the answers, as you try to BEAT THE
SQUARE PEG INTO THE ROUND HOLE!

You need to rethink it and retool it.










__________ Information from ESET NOD32 Antivirus, version of virus signature database 4545 (20091026) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Tom P.]

It's simple, really. Here's the basics of the code:

public class DirectoryListItem : ListViewItem
{
     DirectoryInfo _currentDirectory;

     protected void SetDirectory(string path, bool IsDotDot)
     {
          ..check to make sure the path is real...
          _currentDirectoryInfo = new DirectoryInfo(path);

          if(IsDotDot)
          {
               this.Text = "..";
          }
     }

}

Now, should the Text property (inherited from ListViewItem) be exposed
in the DirectoryListItem_Accessor? Even if I weren't creating the
DirectoryInfo object I'd still have the same issue.

--------------------------------------------------

#1 I was posting to you?

#2 You're not even doing a unit test. You are doing a functional test. By
accessing the filesystem which is what you're doing is a functional test.

If you can't see past your righteous indignation please leave this
thread alone. I thought you had the capacity to see past the personal
indignation, but I guess not.

If you don't understand that nothing the code does above has anything
to do with the access level of the method or proerties, you are not
going to be any help what so ever. I am only tacitly accessing the
filesystem and the instantiation of a DirectoryInfo object has nothing
to do with the access level or state of the inherited properties. You
are still trying to solve a question I'm not asking. I'm not asking if
this is a proper unit test. Stop trying to "win" by moving the
question.

Or, are you are saying that if I comment out the new DirectoryInfo
line above then the framework will suddenly expose the inherited
public members? That's the only line that has anything to do with the
filesystem, so you seem to be asserting that if I comment out that one
line the framework will expose the inherited public member.

Or are you saying that if I change the line to:

_currentDirectoryInfo = new DirectoryInfoMock(path);

....then the wizard will include framework properties in the _Accessor
class?

Hmm, interesting notion.

Tom P.

 

[Tom P.]

Let me add

It has to run in a certain order

This is very similar to (run at same time), but I have seen far too many
people rely on VS's ordering of the tests. rebuild the test runner bits and
you are hosed. ;-)

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog:http://gregorybeamer.spaces.live.com

*******************************************
|      Think outside the box!             |
*******************************************

I appreciate the help George but this guy has shown me that he is only
trolling for righteous indignation. He hasn't brought anything to
light about my question in any of his posts.

And he has now successfully derailed this thread into a topic that,
while interesting, does not address my original question.

Tom P.

 

[Gregory A. Beamer]

I appreciate the help George but this guy has shown me that he is only
trolling for righteous indignation. He hasn't brought anything to
light about my question in any of his posts.

And he has now successfully derailed this thread into a topic that,
while interesting, does not address my original question.

That is probably true. Inheritance is going to be an interesting problem,
especially in light of testing. And I still think you should isolate any
tests in this arena, as you will slow down the test cycle if you create
these functional or integration type tests in a unit test assembly.

Good luck on mulling through things.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************