Well, it’s time to move past the point of good intentions and get started actually writing again. I took a hiatus from my blog for a long time but my goal is to write one short post each week to get me back in the habit. As noted the blog has migrated to a free WordPress site since I don’t see a need to drive my own stack and we’ll see how this goes.
For this post I’d like to discuss testing. In my current role I’m with an organization that is truly dedicated to a Test Driven Development methodology. What this means is we really work to ensure that we write tests before we start developing. (https://msdn.microsoft.com/library/aa730844)
Another piece of background information is that we have strong teams and use a development style known as mobbing. I could reference several links to go into details but I’d like to save that topic for another day. (http://mobprogramming.org/)
However, a good summary is to state that our code is under constant review. As such we tend to strive for code which is very clean. We look to minimize what are known in the industry as “Code Smells”. Something else for a future post: (https://blog.codinghorror.com/code-smells/) – this is currently my favorite post on the topic.
So now in my fourth paragraph, lets get to the point already. As part of our process we create a ‘Test’ project to accompany each assembly (executable or library). This is considered a best practice – however, I’ve seen a code smell consistently emerge from this process. In short we’re frequently guilty of ‘Indecent Exposure’.
As defined at Coding Horror (link above) this means we are guilty of unnecessarily exposing the internals of our classes. We are taking methods which should be private and exposing them as public. (Note my own name for this was ‘interface pollution’ however I think that term may have an overloaded meaning and I like indecent exposure better.)
The issue surfaced during a discussion about interfaces where I was explaining how in C# interfaces are primarily available to allow for polymorphism where we would otherwise look to multiple inheritance. While this is an engaging topic in and of itself, part of my comments were that we need to remember that each class defines it’s primary interface based on it’s public properties and methods.
I then shocked another experienced engineer when I said, that I was looking at potentially suggesting that we consider a ‘test folder’ vs. constantly taking methods which were and/or should be private and making them public to allow our unit tests to access them directly. I also added – in the same breath – that this wasn’t a solution I was suggesting, but something I needed to continue investigating. Note this is yet another great blog topic, but suffice it to say – I favor using separate test projects when feasible.
The challenge of course is that for a really focused test you want to call a method directly at a very low – single action – level. However, most such methods are part of a larger process and shouldn’t be exposed publicly.
In some cases I’ve heard people suggest that we write a test, test the method and then disable(ignore) or discard the test. However, I’m almost as repulsed at this idea as continuing to indecently expose methods. One of the core features of TDD, is that as development continues, it is possible to verify that nothing has broken – and ignoring tests means you lose the largest return value of tests.
Fortunately I was able to find what I consider to be an excellent compromise. Under Visual Studio it is possible to add an attribute to the assembly you are looking to ship that allows it to specify another – test assembly – which can see internals of your implementation. This means you can have your production code register an assembly that can see those methods you designate as ‘Internal’.
[assembly: InternalsVisibleTo(“UnitTestProjectName”)] – this attribute added within your assembly.info file allows you to insert the name of your unit test project and write tests that don’t require the pollution of your public interface.