nunit: System.Reflection.TargetInvocationException after run finished

After running tests (/packages/NUnit.ConsoleRunner.3.5.0/tools/nunit3-console.exe workspace/Tests/ED_DC_Tests.dll --where "cat == _Acceptance" --work workspace --inprocess ) there is error:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object.
   at NUnit.Framework.Internal.PropertyBag.AddToXml(TNode parentNode, Boolean recursive)
   at NUnit.Framework.Internal.Test.PopulateTestNode(TNode thisNode, Boolean recursive)
   at NUnit.Framework.Internal.TestMethod.AddToXml(TNode parentNode, Boolean recursive)
   at NUnit.Framework.Internal.TestResult.AddToXml(TNode parentNode, Boolean recursive)
   at NUnit.Framework.Internal.TestResult.AddToXml(TNode parentNode, Boolean recursive)
   at NUnit.Framework.Internal.TestResult.AddToXml(TNode parentNode, Boolean recursive)
   at NUnit.Framework.Internal.TestResult.AddToXml(TNode parentNode, Boolean recursive)
   at NUnit.Framework.Internal.TestResult.AddToXml(TNode parentNode, Boolean recursive)
   at NUnit.Framework.Internal.TestResult.AddToXml(TNode parentNode, Boolean recursive)
   at NUnit.Framework.Api.FrameworkController.RunTests(ICallbackEventHandler handler, String filter)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark)
   at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at System.Activator.CreateInstance(String assemblyString, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence securityInfo, StackCrawlMark& stackMark)
   at System.Activator.CreateInstance(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence securityInfo)
   at System.AppDomain.CreateInstance(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence securityAttributes)
   at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence securityAttributes)
   at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence securityAttributes)
   at NUnit.Engine.Drivers.NUnit3FrameworkDriver.Run(ITestEventListener listener, String filter)
   at NUnit.Engine.Runners.DirectTestRunner.RunTests(ITestEventListener listener, TestFilter filter)
   at NUnit.Engine.Runners.MasterTestRunner.RunTests(ITestEventListener listener, TestFilter filter)
   at NUnit.Engine.Runners.MasterTestRunner.Run(ITestEventListener listener, TestFilter filter)
   at NUnit.ConsoleRunner.ConsoleRunner.RunTests(TestPackage package, TestFilter filter)
   at NUnit.ConsoleRunner.Program.Main(String[] args)

The error is in some test, because other categories runs good. All tests runs in parallel. Any suggesting to find buggy case?

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 16 (14 by maintainers)

Most upvoted comments

First of all, as to what I meant in introducing two numbered issues is that they could and probably should be two PRs. They solve two different problems and have entirely different levels of urgency. Also, the second point will probably lead to a design discussion. IME PRs have very little fixed overhead so we shouldn’t hesitate to do two of them when needed.

With regard to the second point, I would tend to expose a read-only property bag of our own construction. It would simply not have the setters present that are on IPropertyBag. Since we only use it in one place, it can easily be a one-off class rather than an interface. But as I said, I’d do this in a follow-up PR.

CharliePoole on Jan 18, 2018

Sure, but either way, if you think of me being a long-time NUnit user with the code I showed in the example above, when I upgrade to NUnit 3.10 I start getting compiler errors on my ExtractSpecialProperty(TestContext.CurrentContext.Test.Properties). If we break people’s code, we need to be sure that’s the best option and warn people in the release notes.

jnm2 on Jan 18, 2018

Actually we have two issues here:

The obvious one: a crash is caused by trying to add a property with a null value to the XML. This should probably be prevented by the PropertyBag class itself, since properties are intended to have non-null values. A secondary check could be included in the XML generation so that any null property does not get added to the XML.
The more subtle error is that it has never been intended for users to be able to add properties to a test at execution time or to modify the test properties in any way. This is possible because of an error in the TestAdapter class, which exposes the properties of the internal test instance, permitting possible destructive changes to the properties. I think this has to be fixed as well, making it impossible for users to add or change properties at runtime.

Unfortunately, it seems as if @undron may be making use of this “feature” and other could have discovered it as well. We need to give some thought as to how we can replace this facility. One approach would be a PropertyBagAdapter that allowed addition of new properties, as illustrated here, but not changes to existing ones.

Another approach, which I’ve discussed elsewhere, would be the addition of properties to the test result, which would only be created at the time of executing the test. That would keep the dynamically set properties separate from the static properties that are associated with the test as a result of attributes on the test method. Additionally, the new set of properties could use a standard IDictionary interface rather than the idiosyncratic IPropertyBag interface we use internally.

Let’s use this issue to fix number 1 above and discuss options for number 2. We can create a new issue once we decide on a long-term approach.

CharliePoole on Jan 5, 2017