Posts Tagged ‘.net’

Real Productivity & How Not Having ReSharper Really Hurts

February 8, 2008

Synopsis: ReSharper is a productivity-improving tool for Visual Studio. NOT having it really hurts after getting used to it.

As part of our team evaluation, I have been running ReSharper for the last month. Even though it improved my daily coding routine, I was not able to quantify whether it would be worth the money to buy a license to run it on Visual Studio for me and/or others in the team.

Then we decided to move to Visual Studio 2008 a few days ago. The migration worked fine for everyone except me. I was getting a really weird exception from ReSharper when trying to edit comments. There was also a problem with the key mappings. The only option for me to continue work properly was to uninstall ReSharper.

Now I know how much it really hurts my productivity to not to have this tool.

ReSharper isn’t perfect, by all means. Besides the bug described, it does not execute the NUnit 2.4-style GlobalSetup steps in unit tests, which means I cannot use their beautifully integrated unit testing tools. This has been a known shortcoming for over a year and the fact that JetBrains is not in a rush to fix this worries me. Sometimes I also get stuck in the parameter list popup, which hijacks my cursor keys and cannot be closed with ESC–but maybe that’s just a user error.

But there’s a lot to like: The code quality analyzer running on an open file is very helpful. I made it part of my coding quality process to only commit files that pass the analysis and have the green little square in the upper right corner. The refactoring support is decent (certainly better then what comes with Visual Studio).

I cannot wait for them to fix the comment bug so I can continue using it. There are not any real alternatives to Visual Studio when it comes to .Net and C# development. I would guesstimate that my productivity is down 20% without it (which does not include long-term effects from having lower-quality code because of my oversights that ReSharper’s analysis process would have caught).

The Eclipse Difference

I should note that if I were developing in Java, I would not have any of these problems. Eclipse does most of what the Visual Studio/ReSharper combo does, some of it better. And it’s completely free. Alas, we’re not using Java for this project and–quite frankly–I am currently more fond of C#/.Net for various reasons …

Unit Testing: Allowing Access to Internal Members of Types in Another Assembly

February 5, 2008

Create a Friend Assembly by adding [assembly: InternalsVisibleTo(“Other.Assembly”)] in AssemblyInfo.cs to allow that Other.Assembly access to this assembly’s types’ internal members.

Good object-oriented design involves guarding access to members of types appropriately. Part of a domain object’s state may only be mutated by other types in the same assembly (for example during creation). Those members will be protected with the internal keyword (in .Net).

This causes issues when trying to achieve 100% coverage during testing. Unit tests are usually located in another assembly (even if the namespace is shared for simplicity). That unit test assembly will not have access to the internal members and therefore some important states of a domain object cannot be tested. Assume you have the following domain object assembly:

// assembly Acme.Model
namespace Acme.Model
{
  public class Stuff
  {
    private List _data = new List();
    public ICollection Data { get { _data; } }
    internal void AddData(string data)
    {
       _data.Add(data);
    }
  }
}

We want to test the above class with 100% coverage, meaning we have to get Data added to it. The associated unit test would pretty much look like this, but not compile, because of the inaccessible internal member:

// assembly Acme.UnitTests.Model
namespace Acme.Model
{
  [TestFixture]
  public class TestStuff
  {
    [Test]
    public void TestData()
    {
       Stuff stuff = new Stuff();
       stuff.AddData("data"); // this is not going to compile
       Assert.AreEqual(1, stuff.Data.Count);
    }
  }
}

Declaring a Friend Assembly is a very quick and simple fix for this problem. In Acme.Model’s AssemblyInfo.cs, just add the following line at the end:

[assembly: InternalsVisibleTo("Acme.UnitTests.Model")]

For more on that topic, see Friend Assemblies on MSDN.