All you should ever care about is for your code to be usable, not reusable. A monkey can transform usable code to reusable code, if there are any transformations to be done at all.
The argument "I need this only here" is poor, to put it politely. The technique you're describing is often referred to as the headlines technique and is generally frowned upon.
- You can't test regions, but you can test true methods in isolation.
- Regions are comments, not syntactic elements. In the worst case the nesting of your regions and your blocks contradict each other. You should always strive to represent the semantics of your structure with the syntactic elements of the language you are using.
- After refactoring to methods, one no longer needs folding to read the text. One might be looking at source code in any tool that doesn't have folding, like a terminal, a mail client, a web-view for your VCS or a diff-viewer.
- After refactoring to methods, the resulting method is at least as good as with regions, plus it is simpler to move the individual parts around.
- The Single Responsibility Principle suggests that any unit should have one task and one task only. The task of the "main" method is to compose the "helper" methods to get the desired result. The "helper" methods solve a discrete, simple problem in isolation. The class containing all these methods should also only fulfill one task and only contain the methods related to that task. So the helper methods either belong into the class scope, or the code shouldn't be in the class in the first place, but at least in some global method or, better yet, should be injected.
Also relevant: Jeff Atwoods's thoughts on code folding
Edited following original poster update.
Disclaimer : not a C# programmer (mostly Java or Ruby). My answer would be : I would not test it at all, and I do not think you should.
The longer version is : private/protected methods are not parts of the API, they are basically implementation choices, that you can decide to review, update or throw away completely without any impact on the outside.
I suppose you have a test on FunctionA(), which is the part of the class that is visible from the external world. It should be the only one that has a contract to implement (and that could be tested). Your private/protected method has no contract to fulfil and/or test.
See a related discussion there : https://stackoverflow.com/questions/105007/should-i-test-private-methods-or-only-public-ones
Following the comment, if FunctionB is public, I'll simply test both using unit test. You may think that the test of FunctionA is not totally "unit" (as it call FunctionB), but I would not be too worried by that : if FunctionB test works but not FunctionA test, it means clearly that the problem is not in the subdomain of FunctionB, which is good enough for me as a discriminator.
If you really want to be able to totally separate the two tests, I would use some kind of mocking technique to mock FunctionB when testing FunctionA (typically, return a fixed known correct value). I lack the C# ecosystem knowledge to advice a specific mocking library, but you may look at this question.
Best Answer
As pointed out here, calling
callvirt
is slower, but by a very small margin. I'm not sure how you're getting the CIL code, but as Eric Gunnerson points out, .NET never usescall
for instance classes. It always usescallvirt
, and he even states in a follow-up post that the difference in performance impact is minimum.Just a very quick test, where all classes have a
void PrintTest()
method (which only prints a message to the console)...BaseVirtual
is a base class with the method defined asvirtual
.DerivedVirtual
andDerivedVirtual2
useoverride
to redefine the virtual method, inheriting fromBaseVirtual
.Base
is a regular class with a regular instance method (novirtual
orsealed
).Seal
is asealed
class, just for the kicks.Stat
is a class with the method defined asstatic
.Here's the main code:
And, here's the CIL code:
Nothing too fancy, but this shows that only the
static
method usedcall
. Even so, I don't think this will really make a difference for most applications, so we shouldn't sweat on the small stuff and worry about this.So, in conclusion, as the SO post states, you may get a performance hit because of the lookup the runtime needs to call the virtual methods. Compared to static methods, you get the overhead of
callvirt
.... Well, that was fun...