allure-framework/allure-csharp

InvalidOperationException when calling a function from AllureApi and ExtendedApi outside the Allure context

delatrie opened this issue · 1 comments

I'm submitting a ...

  • bug report
  • feature request
  • support request => Please do not submit support request here, see note at the top of this template.

What is the current behavior?

AllureApi breaks tests if no Allure context is active. The same goes for ExtendedApi.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

Suppose we have the following test in xUnit.net:

using Xunit;
using Allure.Net.Commons;

public class Tests
{
    [Fact]
    public void Test1()
    {
        AllureApi.Step("A noop step");
    }
}

When running it with dotnet test -- RunConfiguration.NoAutoReporters=true, the test fails:

[xUnit.net 00:00:00.25]     MySolution.MyProject.Tests.Test1 [FAIL]
  Failed MySolution.MyProject.Tests.Test1 [22 ms]
  Error Message:
   System.InvalidOperationException : No fixture, test, or step context is active.
  Stack Trace:
     at Allure.Net.Commons.AllureContext.get_CurrentStepContainer()
   at Allure.Net.Commons.AllureLifecycle.StartStep(StepResult result)
   at Allure.Net.Commons.ExtendedApi.StartStep(String name)
   at Allure.Net.Commons.AllureApi.ExecuteAction[T](String name, Action`1 start, Func`1 action, Action pass, Action fail)      
   at Allure.Net.Commons.AllureApi.ExecuteStep[T](String name, Func`1 action)
   at Allure.Net.Commons.AllureApi.Step(String name, Action action)
   at Allure.Net.Commons.AllureApi.Step(String name)
   at MySolution.MyProject.Tests.Test1() in D:\Users\delat\Downloads\start\xunit\xunit-7\tests\MySolution.MyProject\Tests.cs:line 11
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

What is the expected behavior?

The test should run without the error. Some kind of warning might be useful, but no exception should be thrown.

What is the motivation / use case for changing the behavior?

Exception-free API calls would allow the following scenarios that are currently impossible:

  1. Call a helper function that contains some Allure API calls outside the Allure context.
  2. Disable Allure for a class/project:
    • NUnit: by removing [AllureNUnit] from a class
    • xUnit.net: by passing the NoAutoReporters option to the runner.

Please tell us about your environment:

  • Packages version: 2.11.0

Other information

That will probably require some consistent logging mechanism.

Is there any eta for a fix?

We are hitting this when calling methods annotated with AllureStep from within an NUnit SetupFixture, which I think is basically your scenario 1.

This currently doesn't work and results in a test failure:

using Allure.NUnit;
using Allure.NUnit.Attributes;
using Console = System.Console;

[SetUpFixture]
public class AssemblyInit{

    [OneTimeSetUp]
    public void OneTimeSetup()
    {
        Steps.Step1();
    }
}

class Steps
{
    [AllureStep("Step 1")]
    public static void Step1()
    {
        Console.WriteLine("Step 1");
    }

    [AllureStep("Step 2")]
    public static void Step2()
    {
        Console.WriteLine("Step 1");
    }
}

namespace TestProject1
{
    [AllureNUnit]
    public class Tests
    {
        [Test]
        public void Test1()
        {
            Steps.Step2();
        }
    }
}

Commenting out [AllureStep("Step 1")] gets the test running again - but we have many calls to various methods that we'd like to call from our setup fixture and use in our tests, and we currently can't mark those methods with the AllureStep attribute as we'd like (meaning they don't show up in our test reports).

I'm not sure if there is also a slightly seperate issue here that it is failing in the SetupFixture in the first place - tagging the fixture with AllureNunit does not change anything, and we still see the same failure. This may just be unsupported (in which case, maybe it should go in the docs somewhere if it isn't already?)