I have a bunch of classes that wrap DB queries. I want to be able to test-run each query, and verify the result, returned to private members of my class. The perhaps barbaric idea that sprung to mind was to give my query wrappers a public SelfTest() method, visible to XUnit with a [Fact] attribute. As such, my test method would have access to the internals of the class and could verify in detail the outcome of the DB request.
Are there unhappy consequences I should be aware of? I would be adding a public method to my DB wrapper classes, but the method would do no damage. I would be making my application directly 'consumable' by XUnit, rather than having my tests in a separate project as I'm used to, but this seems harmless, no?
Adding the SelfTest() methods to your production code will have no direct impact on the functionality. But your notion that this is kind of
'babaric' is caused by the violation of several principles we know as Clean Code.
Just to name a few points:
First of all this will violate the Single Responsibilty Principle. Beside the functionality itsself the class has the responsibility to test itsself.
More code and more complexity is added to the class. Who wants to read all the test code if someone is just interesting in understanding the functionality ?
You add additional dependencies to your production code (XUnit in this case) and the assemblies will be part of your shipped product.
But what is an alternative approach ?
Just making all methods and properties public for the sake of testing is not suitable as well. But with the InternalsVisibleTo annotation in the assembly.cs you can give the test project assembly the right to access internal methods and properties of the assembly to test.
Example:
Add in the assembly.cs of MyAssembly the line
[assembly:InternalsVisibleTo("MyAssembly.UnitTests")]
Then in MyAssembly.UnitTests internal methods can be used.
Before deploying my project, I would like to set all public methods to internal methods. Does someone know a built-in function in Visual Studio or an external tool to do such tasks?
With some trivial refactoring, ILMerge can work here. ILMerge can merge multiple assemblies into one, and change the accessibility of everything that is not part of the primary assembly to internal. By separating your current project into two projects (a library containing all the code, and a helper executable that does nothing but forward to the real code in the library), you can, after a build, merge them back into a single file, in which all the library bits are no longer public.
If you have properties/methods public for test reasons you should have a look at Brad Wilsons blog: Testable Object Pattern
This way you don't have to switch, everything stays internal in development.
Or have a look at Jon Skeets suggestion on InternalsVisibleTo
I can only think of two reasons you would want to do this:
Security. In this case you have the wrong idea: access modifiers are not a security mechanism. They are a design concern, describing how an API presents itself. Any debugger will still give access to all your methods, regardless of their access modifiers.
You have another assembly that you use during development that should have full access. In this case you can leave everything internal and make it a friend assembly.
I don't mean to troll but I really don't get it. Why would language designers allow private methods instead of some naming convention (see __ in Python) ?
I searched for the answer and usual arguments are:
a) To make the implementation cleaner/avoid long vertical list of methods in IDE autocompletion
b) To announce to the world which methods are public interface and which may change and are just for implementation purpose
c) Readability
Ok so now, all of those could be achieved by naming all private methods with __ prefix or by "private" keyword which doesn't have any implications other than be information for IDE (don't put those in autocompletion) and other programers (don't use it unless you really must). Hell, one could even require unsafe-like keyword to access private methods to really discourage this.
I am asking this because I work with some c# code and I keep changing private methods to public for test purposes as many in-between private methods (like string generators for xml serialization) are very useful for debugging purposes (like writing some part of string to log file etc.).
So my question is:
Is there anything which is achieved by access restriction but couldn't be achieved by naming conventions without restricting the access ?
There are a couple questions/issues that you are raising, so I'll handle each one separately.
How do I test private methods?
Beyond the debate/discussion of if you should test private methods, there are a few ways you can do this.
Refactor
A broad general answer is that you can refactor the behaviour into a separate testable class which the original class leverages. This is debatable and not always applicable depending on your design or privileges to do so.
InternalsVisibleTo
A common routine is to extract testable logic into a method and mark it as internal. In your assembly properties, you can add an attribute [InternalsVisibleTo("MyUnitTestingProject")]. This will allow you to access the method from your unit testing project while still hiding access to all other assemblies. http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx
However, given the comments made by you, you are unable to change the structure of source code permanently in your workplace; that you are changing the accessors to test, test, then change them back before committing. In this case there are two options:
Partial testing classes
If you mark the class as partial. Create a second partial class file which will contain your tests (or public wrappers to the private members). Then when it comes time to merge/commit, just remove your partial classes from the project and remove the partial keyword from the main class. In addition, you can wrap the entire testing code file with if DEBUG (or other directive) so it's only available when unit testing and will not affect production/development code.
http://weblogs.asp.net/ralfw/archive/2006/04/14/442836.aspx
public partial class MyClass
{
private string CreateTempString()
{
return "Hello World!";
}
}
#if DEBUG
public partial class MyClass //in file "MyClass_Accessor.cs"
{
public string CreateTempString_Accessor()
{
return CreateTempString();
}
}
#endif
Reflection
You can still access private members via reflection:
public class Test
{
private string PrivateField = "private";
}
Test t = new Test();
var publicFieldInfo = typeof(Test).GetField("PrivateField", BindingFlags.Instance | BindingFlags.NonPublic);
Console.WriteLine(publicFieldInfo.GetValue(t)); //outputs "private"
Your unit tests could pull out private/hidden data in classes this way. In fact, Microsoft provides two classes that do exactly this for you: PrivateObject and PrivateType
Given your in-house development process limitations, this is likely your best bet as you'll be able to manage your own tests outside the main project libraries without having to alter anything in the core code.
Note that Silverlight (and likely other Core-CLR runtimes) strictly enforce non-public access during reflection, so this option is not applicable in those cases.
So, there are a few ways to test private members, and I'm sure there are a few more clever/not-so-clever methods of doing so lurking out there.
Could all of those benefits could be achieved by naming all private methods with __ prefix or by introducing a private-but-accessible access modifier?
The benefits cited by you (citing others) being:
To make the implementation cleaner/avoid long vertical list of
methods in IDE autocompletion
To announce to the world which methods are public interface and
which may change and are just for implementation purpose
Readability
Now you add that these could all be achieved with __ or by a change to the language specification and/or IDEs that would support a private-but-accessible access modifier, possibly with some unsafe-like keyword that would discourage this. I don't think it will be worthwhile going into a debate about changing the current features/behaviours of the language and IDE (and possibly it wouldn't be make sense for StackOverflow), so focusing on what is available:
1) Cleaner implementation and intellisense
The Visual Studio IDE (I can't speak for MonoDevelop) does support hiding members from intellisense when they're marked with the [EditorBrowsableAttribute]. But this only works if the developer enables the option "Hide Advanced Members" in their Visual Studio options. (note that it will not supress members in the intellisense when you're working within the same assembly)
http://msdn.microsoft.com/en-us/library/system.componentmodel.editorbrowsableattribute.aspx
So marking a public member as such makes it behave (intellisense-wise) as internal-ish (no [InternalsVisibleTo] support). So if you're in the same assembly, or if you do not have the Hide Advanced Members enabled, you'll still see a long list of __ members in the intellisense. Even if you have it hidden from intellisense, it's still fully accessible according to its current access modifier.
2) Public usage interface/contract
This assumes that all developers in the C#, and Visual Basic, and F#, and C++.NET and any .NET development world will adopt the same __ naming convention and adhere to it as assemblies are compiled and interchanged between developers. Maybe if you're scripting in IronPython, you can get away with it, or if your company internally adopts this approach. But generally speaking, it's not going to happen and .NET developers may likely be hestitant to leverage libraries adopting this convention as that is not the general .NET culture.
3) Readability
This kind of goes with #2 in that what is "readable" depends on the culture and what developers within that field expect; it is certainly debatable and subjective. I would wager that the majority of the C# developers find the strict/enforced encapsulation to significantly improve code readability and I'm sure a good chunk of them would find __ used often would detract from that. (as a side, I'm sure it's not uncommon for developers to adopt _ or __ prefixes for private fields and still keep them private)
However, readability and encapsulation in C# goes beyond just public/private accessors. In C#, there are private, public, protected internal, protected, and internal (am I missing one?) each has their own use and provide different information for developers. Now I'm not sure how you would go about communicating those accessors only via __. Suggesting single underscore is protected, double underscore is private, that would definitely hamper readability.
Is there anything which is achieved by access restriction that couldn't be achieved by naming conventions without restricting the access?
If you're asking why did the C# design team go this route, well I guess you'd have to ask Mr. Hejlsberg one day. I know they were creating a language gleaning the best parts of C/C++ and to strongly focus on the priciples of object-oriented principles.
As to what is achieved by enforcing access via the access modifiers:
More guaranteed proper access by consumers of the API. If your class utilizes a MakeTempStringForXMLSerialization method which stores the string as a class property for serialization, but for performance reasons forgoes costly checks (because you, as a developer have done unit testing to ensure that all of class's fields will be valid via the public API) then a third party does some lovely garbage-in-garbage-out, they'll blame you and/or the vendor for a shoddy library. Is that fair? Not necessarily; they put the garbage in, but the reality is many will still blame the vendor.
For new developers attempting to understand how your API works, it helps to simplify their experience. Yes, developers should read the documentation, but if the public API is intuitive (as it generally should be) and not exposing a boatload of members that shouldn't be accessed, then it's far less confusing and less likely they'll accidentally feed garbage into the system. It will also lower the overhead to get the developers to consume and leverage your API effectively without hassles. This is especially the case when it comes to any updates you publish of your API in which you wish to change/refactor/improve your internal implementation details.
So from a business perspective, it protects them from liability and bad relations with customers and is more appealing for developers to purchase and invest in it.
Now this can all be the case, as you say, if everyone follows the convention that __ members should not be accessed outside of the class or provide some unsafe marker where you say, "If you do this, and it breaks, it's not my fault!" well then you're not on the same planet as C# .NET development. The accessors provided by C# provide that __ convention but ensure that all developers adhere to it.
One could argue that the restricted access is an illusion as consumers can work around it via reflection (as demonstrated above), and thus there is actually no programmatic difference between the access modifiers and __ (or other) notation. (On Silverlight/Core-CLR, there is, most definitely a programmatic difference though!) But the work developers would go through to access those private fields is the difference between you giving consumers an open door with a sign "don't go in" (that you hope they can read) and a door with a lock that they have to bash down.
So in the end what does it actually provide? Standardized, enforced access to members where as __ provides non-standardized, non-enforced access to members. In addition, __ lacks the range of description that the varieties of available access modifiers supply.
Update (January 2nd, 2013)
I know it's been half a year, but I've been reading through the C# language specification and came across this little gem from section 2.4.2 Identifiers which states:
Identifiers containing two consecutive underscore characters (U+005F)
are reserved for use by the implementation. For example, an
implementation might provide extended keywords that begin with two
underscores.
I imagine nothing necessarily bad will happen, most likely nothing will break catastrophically if you do. But it's just one more aspect that should be considered when thinking about using double underscores in your code that the specification suggests that you do not.
The reason private methods exist are to provide encapsulation.
This allows you to provide public contracts by which you want your object to interact, yet have your internal logic and state be encapsulated in a way that refactoring would not affect consumers.
For example, you could provide public named properties, yet decide to store state in a Dictionary, similar to what typed DataSets do.
It's not really a "Security" feature (since you always have reflection to override it), but a way to keep public APIs separate from internal implementations.
Nobody should "depend" on your internal and private implementation, they should only depend on your public (or protected) implementation.
Now, regarding unit testing, it is usually undesired to test internal implementations.
One common approach though is to declare it internal and give the test assemblies access, through InternalsVisibleToAttribute, as Chris mentioned.
Also, a clear distinction between public, private, and protected are extremely useful with inheritance, in defining what you expect to be overridable and what shouldn't.
In general, there is no real point to marking fields or methods private. It provides an artificial sense of security. All the code is running inside the same process, presumably written by people with a friendly relationship to each other. Why do they need access controls to protect the code from each other? That sounds like a cultural issue to fix.
Documentation provides more information than private/protected/public does, and a good system will have documentation anyway. Use that to guide your development. If you mark a method as "private", and a developer calls it anyway, that's a bad developer, and he will ruin your system in some other way eventually. Fix that developer.
Access controls eventually get in the way of development, and you spend time just making the compiler happy.
Of course, if you are talking strictly about C#, then you should stick to marking methods as private, because other C# developers will expect it.
It hides a lot of internal details, especially for library implementers who may actually want to hide those details.
Keep in mind that there are commercial libraries out there, being sold. They expose only a very limited set of options in their interface to their users and they want all the rest to be well hidden.
If you design a language that doesn't give this option, you're making a language that will be used almost exclusively for open-source projects (or mostly for scripting).
I don't know much about Python though, would be interesting to know if there are commercial closed-source libraries written in python.
The reasons you mentioned are good enough too.
If you're publishing a library with public members, it's possible for users to use these members. You can use naming conventions to tell them they shouldn't, but some people will.
If your "internal" members are public, it becomes impossible for you to guarantee compatibility with the old version of the library, unless you keep all of the internal structure the same and make only very minor changes. That means that every program using your library must use the version it was compiled against (and will most likely do this by shipping its own version, rather than using a shared system version).
This becomes a problem when your library has a security update. At best, all programs are using different shared versions, and you have to backport the security update to every version that's in the wild. More likely, every program ships its own version and simply will not get the update unless that program's author does it.
If you design your public API carefully, with private members for the things you might change, you can keep breaking changes to a minimum. Then all programs/libraries can use the latest version of your library, even if they were compiled for an earlier one, and they can benefit from the updates.
This can lead to some interesting debate. A main reason for marking private methods (and member variables) is to enforce information hiding. External code shouldn't know or care about how your class works. You should be free to change your impl without breaking other things. This is well established software practice.
However in real life, private methods can get in the way of testing and unforeseen changes that need to occur. Python has a belief "we're all consenting adults" and discourages private methods. So, sometimes I'll just use naming conventions and/or comment "not intended for public use". It's another one of those OO-theory vs. reality issues.
I'm aware of (and agree with) the usual arguments for placing unit tests in a separate assembly. However, of late I've been experiencing some situations where I really want to be testing private methods. The behind-the-scenes logic in question is complex enough that testing the public and internal interfaces doesn't quite get the job done. The testing against the class's public interface feels overwrought, and I see several spots where a few tests against privates would get the job done more simply and effectively.
In the past I've tackled these kinds of situations by making the stuff I need to test protected, and creating a subclass that I can use to get at it in the test framework. But that doesn't work so well on classes that should be sealed. Not to mention bloating the test framework with all that scaffolding.
So I'm thinking of doing this instead: Place some tests in the class, where they can get at the private members. But keep them out of the production code using '#if DEBUG`.
Does this seem like a good idea?
Before anybody asks...
The solution to OP's problem is to properly incorporate IoC with DI and eliminate the need of testing private method altogether (as Joel Martinez noted). As it's been mentioned multiple times, unit testing private members is not the way to go.
However, sometimes you just can't change the code (legacy systems, risk of breaking changes - you name it) nor you can use tools that allow private members testing (like Typemock, which is paid product). For such cases, you can either not test at all, or cut corners. Which I believe is situation OP's facing.
Leaving private methods testing discussion aside...
Remember you can use reflection to access and invoke private members.
In my opinion, placing conditional debugs in the class itself is rather bad idea - it adds noise (as in, something unrelated) to the class code. Sure, it will be gone in release, but you (and possibly other programmers) will have to deal with it on the daily basics.
I realize your idea might sound good on paper - simple test wrapped with conditional debug. But in reality, tests quickly turn out to use extra variables (those will also have to be placed in the class code), some utility (extra references, custom types), testing frameworks (even more references) and what not. This all will have to be somehow connected to the class code. Put that all together, and you quickly end up with an unmaintanable monster.
Are you sure you want to deal with that? Especially considering that throwing together simple reflection-based utility is probably not that hard.
Everything you're referring to can be solved with just two concepts: Single Responsibility Principle, and Dependency Injection. It definitely sounds like you need to simplify your classes. Mind you, that doesn't mean the class must offer less value, it just means that the internals need to be simpler and some functionality may have to be delegated to others.
If you need to test this method independently of the public API of the class, then it sounds like a candidate for being removed from the class itself.
You could say the class is dependent on the private method (as is arguably evident by the need to test it separately from the class public API).
If this dependency cannot be satisfied through testing the public API of the type alone then have the class instead delegate this dependency to another type. You can either instantiate this type internally or have this type injected / resolved.
This new type can then have its own unit tests, as it's public API will be expressing what was previously a private method.
Told by my boss to use Moq and that is it.
I like it but it seems that unlike MSTest or mbunit etc... you cannot test internal methods
So I am forced to make public some internal implementation in my interface so that i can test it.
Am I missing something?
Can you test internal methods using Moq?
Thanks a lot
You can use the InternalsVisibleTo attribute to make the methods visible to Moq.
http://geekswithblogs.net/MattRobertsBlog/archive/2008/12/16/how-to-make-a-quotprotectedquot-method-available-for-quotpartialquot-mocking-and-again.aspx
There is nothing wrong with making the internals visible to other classes for testing. If you need to test the internals of a class, by all means do so. Just because the methods are not public does not mean you should ignore them and test only the public ones. A well designed application actually will have a majority of the code encapsulated within your classes in such a way that they are not public. So ignoring the non-public methods in your testing is a big mistake IMHO. One of the beauties of unit testing is that you test all the parts of your code, no matter how small and when your tests are all up and running at 100% it is a very reasonable assumption that when all these parts are put together, your application will work properly for the end user. Of course verifying that latter part is where integration level tests come in - which is a different discussion. So test away!!!
If you have many code that isn't tested by the public methods, you probably have code that should be moved to another classes.
As said in another answer, you can use the InternalsVisibleTo attribute for that. But that doesn't mean you should do it.
From my point of view Mocking should be used to mock up some behavior that we are dependent on but are not setting out to test. Hence:
Q: Am I missing something?
- No you're not missing anything, MOQ is missing the ability to mock private behaviors.
Q: Can you test internal methods using Moq?
- If the result of the private behavior is visible publicly, then yes you can test the internal method but it's not because of Moq that you can test them. I would like to make a point here is that Mock is not the ability to test but rather the ability to similar behaviors that we are not testing but depend on.
C: A main benefit with TDD is that your code becomes easy to change. If you start testing internals, then the code becomes rigid and hard to change
- I don't agree with this comment for 2 main reasons:
1: It is not a beginner misconception, as TDD is not just about the ability to code faster but also better quality code. Hence the more test we can do the better.
2: It doesn't make the code anymore harder to change if you can somehow can test the internal methods.
Your initial presumption that it is necessary to test internal method is a common beginners misconception about unit testing.
Granted, there may exist cases where private methods should be tested in isolation, but the 99% common case is that the private methods are being tested implicitly because they make the public methods pass their tests. The public methods call the private methods.
Private methods are there for a reason. If they do not result in external testable behaviour, then you don't need them.
Do any of your public tests fail if you just flat out delete them? If yes, then they are already being tested. If not, then why do you need them? Find out what you need them for and then express that in a test against the public interface.
A main benefit with TDD is that your code becomes easy to change. If you start testing internals, then the code becomes rigid and hard to change.
InternalsVisibleTo is your friend for testing internals.
Remember to sign your assemblies and you're safe.