Accessing Private Members in C#

I recently created a class that needed internal visibility; however, I wanted to unit test the methods of the class. I always put my tests in a separate library and couldn't access my class to test it. This brought me to the question, how do you limit the visibility of your classes (or methods etc) in release code, but still make it visible enough to test?

I knew I could use reflection; however, I was looking for a simpler example. I've never gone down the reflection road for unit testing, but it sounds more complicated than necessary. I decided to use conditional compilation like so:

#if TESTING
public
#else
internal
#endif

Obviously, I changed my NAnt build file to define the conditional compilation symbol TESTING, compile, run NUnit, and recompile without the TESTING symbol.

This worked, but made my method signatures ugly:

#if TESTING
public
#else
internal
#endif
void Foo()

So, I threw a #region into the mix and they now look like this

TESTING?public:internal
void Foo()

I heard another idea at ThoughtWorks. You could create a properly visible interface that you ask developers to code to. Then make your actual classes more visible to allow testing. This works also, but still increases complexity in my opinion. Also, I like to use NDoc to generate my documentation and it will document all my public classes that I'd probably like hidden. Sure, I can explicitly exclude things from NDoc, but that seems like a lot of work. Conditional compilation will give me correct visibility with the only sacrifice being my signature split to 2 lines.

Development in Visual Studio 2005 February CTP

I've been developing in Visual Studio 2005 (February CTP) for a few weeks now and thought I'd talk about the experience so far.

Installation: Fairly painless on the surface. Unfortunately, after a "successful" installation I found that I could not view Content Pages in Design View. Now, I don't consider not being able to use Design View a deal breaker; however, when I switched to Design View VS2005 would stop accepting keystrokes and became unusable. Obviously, I could just decide to never use Design View, but I didn't feel like that was an acceptable solution. After 12 hours of installation and uninstallation I managed to get it working. I have no idea which variable I switched that caused it to work. The only advice I can give is to uninstall everything that VS2005 installs, and perform a custom install and only install the things you absolutely need. Rebooting between each step seems to help also. I gave this advice to a co-worker and he still got 2 failed installs before he got it to work. If you are concerned about the same problem I'd suggest setting up a Virtual PC before installing and uninstalling repeatedly. Another co-worker installed one time and it worked.

Developing: So far we are only taking advantage of Master Pages and Generics but it's worked out pretty well. The only gotcha I've come across is when you rename a Content Page it will no longer compile. Which shouldn't be a problem because you should probably name your pages Default.aspx, Default2.aspx, Default3.aspx, etc anyway. Mike Ward actually found the solution which is to manually change the Inherits value of the Page directive tag to match the name of the class in the code behind. The refactoring is decent, but not yet as good as ReSharper.
The thing I really like about VS2005 is that I no longer have to declare the controls in the code behind before I can access their values.

Building: Building in VS2005 is painless. The only issue I've run into is when using MSBuild to build a solution that contains a File System Web Site. The references for a File System Web Site are added to a solution file; however, MSBuild doesn't seem to pick the references up and can fail. When you add the reference in VS2005 a Bin folder is created and the referenced project's library is added. However, on a CI machine things can get tricky. I've heard 2 work arounds that are a bit sloppy, but I hear MSBuild beta 2 will fix the issue.

Dependency Injection, Pico Container, and Good Citizens

Dependency Injection is a hot topic these days. If you aren't familiar with DI, I suggest you read Martin's paper. If you are familiar, don't worry, I'm not going to rehash it.

Actually, I want to point you in the direciton of Pico Container. PicoContainer is a lightweight container that can modularize how dependencies between parts of your application are laced up. Additionally, it will improve the testability of your code and improve how components are configured in application.

Lastly, while reading the Pico Container documentation I came across this page about creating classes that are Good Citizens. Even if you never use Pico Container, this page is well worth your time. The ideas presented about being a "Good Citizen" aren't specific to Pico, but are specific to good code.

Pragmatic Version Control using Subversion

I recently picked a great book: Pragmatic Version Control using Subversion by Mike Mason. I have previously used both CVS and VSS. I never administered either one, I just trusted them to do source control for me. My teams always had a version control resource; therefore, the most I ever really needed to know was how to check in. Do you care? Probably not, but it gives you some context as to my level of experience with version control previous to reading the book.

Now that we have my background covered, on to the review. I really enjoyed the book! Mike manages to cover the important (and sometimes not so important) functions that Subversion offers while holding your attention the whole time. I found the book to be easy to follow and it provided good examples in both Windows and Unix. By following the examples I had my own repository up and running in no time. After reading a few chapters I felt comfortable working with Subversion and would have no problem using it in a professional environment.

So the book is great, but what about Subversion itself? Well, the short answer is, it's great. They fixed several things that many developers felt that were missing from CVS. Additionally, the staff that helped create Subversion were almost all CVS experts. Therefore, if you are comfortable using CVS the jump to Subversion should be a very easy one. If you are stuck using VSS, the jump is harder, but even more worth it. The software is free for download on the Tigris site.

Patterns of Enterprise Application Architecture

Have you read Patterns of Enterprise Application Architecture? If so, have you referenced it recently? I first picked up the book 2 years ago and loved it. However, in the time between then and now I haven't referenced it near as much as I should have been. The good news is several of the solutions I've developed in the that time used several of the patterns Martin describes in the book. The bad news is I likely wasted a lot of development time while I was moving towards the patterns due to trial and error.

The moral of the story (for me anyway) is it's not good enough to just read a book and retain the things you agree with or like. Take the time to know all the topics discussed in the book and reference it if you find yourself in the situation where you need a pattern you weren't previously familiar with. Additionally, take the time to skim your pattern books now and then. You would be amazed how much good information seemed irrelevant the first time you read it. If you stick to the good patterns books, it's likely that every pattern has been the right choice at one time or another. You never know when a previously discarded pattern is exactly what you need currently.