Testing Question
-
I'm fairly new to writing unit tests and I've run into something of a design/architecture question. I'm operating under the belied that any given method should not be overly large, and any that is should be refactored into smaller methods. As a result I end up with this:
public MyClass : IMyClass
{
public string MyMainMethod()
{
Method1();
Method2();
return "somestring";
}private void Method1() { // some code } private void Method2() { // some other code }}
Obviously this is grossly simplified, but it serves my purposes for this question. I have my classes loosly couples so when writing a unit test I can stub any interface that is injected into MyClass and isolate the code under test. How do I go about stubbing Method1 and Method2? I'm using Moles (and can't change because of company restrictions), but I suspect/hope this is a testing platform independent question. Should I be desiging this different? Not using private methods, but public virtual would allow me more flexibility, but doesn't feel like the right approach. Any advice or pointers would be greatly appreciated. - Andrew
-
I'm fairly new to writing unit tests and I've run into something of a design/architecture question. I'm operating under the belied that any given method should not be overly large, and any that is should be refactored into smaller methods. As a result I end up with this:
public MyClass : IMyClass
{
public string MyMainMethod()
{
Method1();
Method2();
return "somestring";
}private void Method1() { // some code } private void Method2() { // some other code }}
Obviously this is grossly simplified, but it serves my purposes for this question. I have my classes loosly couples so when writing a unit test I can stub any interface that is injected into MyClass and isolate the code under test. How do I go about stubbing Method1 and Method2? I'm using Moles (and can't change because of company restrictions), but I suspect/hope this is a testing platform independent question. Should I be desiging this different? Not using private methods, but public virtual would allow me more flexibility, but doesn't feel like the right approach. Any advice or pointers would be greatly appreciated. - Andrew
Andrew, there are two schools of opinion on this. In one school, you'd effectively elevate the visibility of these methods purely for the purpose of testing. In the second school, you wouldn't directly test these methods. Instead, you'd test the public method that called them. In other words, if there were no route to your private method, then it shouldn't exist.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
Andrew, there are two schools of opinion on this. In one school, you'd effectively elevate the visibility of these methods purely for the purpose of testing. In the second school, you wouldn't directly test these methods. Instead, you'd test the public method that called them. In other words, if there were no route to your private method, then it shouldn't exist.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierThat makes sense. I guess I was trying to be able to test the private methods individually and separately from the public method that calls them. It sounds like you're saying I could just test them through tests on the public method. This feels cleaner to me, I really didn't like the idea of elevating them just for tests. I made them private for a reason, changing that just for a test felt wrong. Thanks for the feedback, Pete.
-
I'm fairly new to writing unit tests and I've run into something of a design/architecture question. I'm operating under the belied that any given method should not be overly large, and any that is should be refactored into smaller methods. As a result I end up with this:
public MyClass : IMyClass
{
public string MyMainMethod()
{
Method1();
Method2();
return "somestring";
}private void Method1() { // some code } private void Method2() { // some other code }}
Obviously this is grossly simplified, but it serves my purposes for this question. I have my classes loosly couples so when writing a unit test I can stub any interface that is injected into MyClass and isolate the code under test. How do I go about stubbing Method1 and Method2? I'm using Moles (and can't change because of company restrictions), but I suspect/hope this is a testing platform independent question. Should I be desiging this different? Not using private methods, but public virtual would allow me more flexibility, but doesn't feel like the right approach. Any advice or pointers would be greatly appreciated. - Andrew
If there is some need for verifying the code of those functions, I'd use either: -
protectedinstead ofprivateand create a sub-class for testing - reflection for invoking the private methods. But testing is normally about public functions only. And you may have found a situation where that stringency is not fully appropriate. -
I'm fairly new to writing unit tests and I've run into something of a design/architecture question. I'm operating under the belied that any given method should not be overly large, and any that is should be refactored into smaller methods. As a result I end up with this:
public MyClass : IMyClass
{
public string MyMainMethod()
{
Method1();
Method2();
return "somestring";
}private void Method1() { // some code } private void Method2() { // some other code }}
Obviously this is grossly simplified, but it serves my purposes for this question. I have my classes loosly couples so when writing a unit test I can stub any interface that is injected into MyClass and isolate the code under test. How do I go about stubbing Method1 and Method2? I'm using Moles (and can't change because of company restrictions), but I suspect/hope this is a testing platform independent question. Should I be desiging this different? Not using private methods, but public virtual would allow me more flexibility, but doesn't feel like the right approach. Any advice or pointers would be greatly appreciated. - Andrew
Hi, If you want to know how much of your private code is tested by your unit tests, there are tools to measure test coverage e.g. NCover. Such a tool may report which code lines are not hit by tests. Usually, each assembly is assigned a minimum coverage that must be reached. A 100% coverage can actually be very difficult to reach. Getting the coverage feedback can be a useful experience. You could get more conscious about how your coding style can make testing easier; branches and exceptions are usually up for discussion. Kind Regards, Keld Ølykke