Before making a commit, I prefer to run all hundred-something unit tests in my C# Solution, since they only take a couple minutes to run. However, if I've already run them all, all is well, and then I decide to organize the using directives in my Solution, is it really necessary to re-run the unit tests? I have a macro that goes through all files in the Solution and runs Visual Studio's 'Remove and Sort' command on each. In my understanding, so long as all projects still build after using directives are changed around, things should be fine at runtime, too. Is this correct thinking?
views:
60answers:
3
A:
Yes. Re-running the unit tests is not necessary. The order of using directives does not matter to the compiler.
Stephen Cleary
2010-05-27 20:35:26
Well, that command in Visual Studio both reorders `using` directives and removes ones it thinks are not necessary.
Sarah Vessels
2010-05-27 20:41:57
@Sarah: true. But I've never seen it make a mistake and remove one that I was using. That's the only way it would break.
Stephen Cleary
2010-05-27 20:44:56
+1
A:
It will not matter.
Personally though, I'd still run tests prior to committing any code.
Finglas
2010-05-27 20:38:37
See man, that's why I'm asking: I'm just as paranoid! Why would you re-run if it built?
Sarah Vessels
2010-05-27 20:39:18
With automated build processes - any change (the reordering of usings being no exception) will cause a new build to be kicked off if you were to use an automated build. Personally this is a good thing. At least you won't be labeled as breaking the build. Plus, one of the benefits of unit tests is to allow to you to be confident, and thus void of paranoia when you commit your code. If re-running unit tests removes this paranoia, go for it - what's the harm? ;)
Finglas
2010-05-27 20:41:13
I'd re-run the tests simply because once you start making exceptions it's far easier to let breaking changes get by on "oh, it's a super simple change". Test then commit always, keeping the repository in a working state is worth a few extra unit tests.
Josh Sterling
2010-05-27 20:47:43
+2
A:
Well, it partly depends on how much you trust the "remove and sort" feature. As far as I'm aware, the ordering doesn't matter - but which directives are present can matter.
For example, suppose you had this extension method:
public static int Count<T>(this List<T> source)
{
return 0;
}
If this were in a type in a namespace MyExtensions, and the original code was this:
using MyExtensions;
using System.Linq;
...
List<string> list = new List<string>();
int x = list.Count();
then removing the first using directive would make no difference to the visible compiler output (i.e. no errors, no warnings) but it would change which extension method was called.
Now I personally trust that "remove and sort" won't actually make such a behaviour-changing alteration, and you'd have to have some pretty brittle code to start with... but I just thought I'd mention that "it still builds afterwards" isn't actually enough to guarantee that your tests will still work.
Personally I'd probably run the tests again anyway, but equally I'd be reasonably happy not to if necessary. As Finglas mentions, if you've got a continuous build system alerting you to breaking changes anyway, the consequences of very occasionally getting it wrong probably aren't too disastrous. Of course, if you've got thousands of developers who will be inconvenienced by broken code getting checked in, that's a different matter.
Jon Skeet
2010-05-27 20:42:51