Andy Johns' Blog

Doesn't this kinda go against the idea that components should be decoupled largely from any fore-knowledge (design time) of context in which they run?

I think that folks typically people prefer to use config files because they are the tool that supports this kind of design imperative.

Wouldn't it make more sense to have a single class that represents and controls all message output that can write to all of the output targets, and that the output target can be set using a public member whose runtime state is persisted in a config file?

The solution you provide is a pretty cool example of walkig the stack, but it creates a design dependency that doesn't quite smell right to me. Wouldn't the target component need to be bound to nunit-framework.dll in order for this to work?

You make some good points, but I also see a need for this. I don't like changing config files for unit testing. Not only can it create problems with Continuous Integration but it can also be misused easily. The whole application can know that it's in test mode, and thus more code paths can be targeted against it. And if you have multiple config files it introduces potential problems, one dll’s config is flagged “under test” but not another’s, etc. And if you’re also managing multiple config files for multiple environments it can get to be quite a headache. Also, in my case our QA team does not allow any changes to code or config files while testing.

I definitely believe the use of this detection should be limited. For my current project, we're only using it in a custom MessageBox type dialog that is displayed during an error condition. The main drive for this was the fact our continuous integration service, CruiseControl, (aka CCNet) was hanging when the UI displayed a messagebox during unit testing. Because CCNet hung, the test looked successful, however it was not.

As far as having a dependency to NUnit in the target assembly, this is not a problem for me, as I always put my test classes inside my target assemblies. It is far easier to maintain this way, allows for easier testing of internals without reflection, and allows easier unit testing of classes in executables. We also run NUnit tests against some production systems to ensure successful production rollout.

Finally to address your first point that components should be decoupled from any knowledge of the context in which they run.... I think that good TFD dictates you always are aware that the code will run within unit testing, and you have to code for that. Any technique, config files, this function, or something else to block MessageBoxes, or other GUI elements during unit testing indicates your component is aware it’s being run under test conditions; and while this awareness should be limited, it is needed in some cases.

I needed to do this detection but have it work even with NUnit-compatible test frameworks (such as MBUnit) so I had to remove the dependency on the NUnit attribute, like this:

Array Attributes = methodBase.GetCustomAttributes(false);
foreach (object obj in Attributes)
{
if (obj.ToString().Contains("TestAttribute"))
return true;
}

This won't always work because test methods do not necessarily have the TestAttribute set. They are also recognized as test methods if they case-insensitively start with "test", and in this case the above methods will fail.

[SetUpFixture]
public class NUnitDetector
{
private static bool nunitRunning = false;
public bool NUnitRunning { get { return nunitRunning; } }

[SetUp] public void S() { nunitRunning=true; } }
[TearDown] public void T() { nunitRunning=false; } }
}

Oh, i forgot:

public STATIC bool nunitRunning ...

Rueschi -
You code is fine for small cases, but it requires the tested code to have a reference to the test assembly, and it assumes one test fixture will be the only test fixture that will test the code. Often in a large project you may have dozens of test assemblies, with hundreds of test fixtures, and some code will be called from many tests....