Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    HBInspiretec
    @HBInspiretec
    @SabotageAndi - I've had a look at the code but it doesn't make sense to me, sorry . I'll have to wait for a future fix.
    Andreas Willich
    @SabotageAndi
    Ok, but be aware that will take a while.
    Probably until we hit the problem ourself somewhere
    Mark Hoek
    @mbhoek
    @SabotageAndi Sorry if I sound stupid, but did you mean I need to add the plugin to Available-Plugins myself or is that something only you can do?
    Andreas Willich
    @SabotageAndi
    @mbhoek you can add it yourself. The wiki is editable by everybody with a GitHub account.
    Approx 1h later it is then visible on the documentation on specflow.org
    HBInspiretec
    @HBInspiretec
    @SabotageAndi Yes, sorry not to be of much use. However, at I can at least help with any Alpha release testing - just let me know if I can assist with that.
    Mark Hoek
    @mbhoek
    @SabotageAndi I have added the link to the github wiki, but it now shows a horizontal scroller. I think it will be alright on the specflow.org website, but would you please be so kind to verify if my change is ok?
    Andreas Willich
    @SabotageAndi
    @mbhoek It looks ok on the website. That is what counts. ;-)
    Mark Hoek
    @mbhoek
    @SabotageAndi Thank you. Like I said, I'm new to open source so I don't want to mess things up.
    Josh Keegan
    @JoshKeegan
    @SabotageAndi I've added my plugin to the list on GitHub https://github.com/techtalk/SpecFlow/wiki/Available-Plugins but it doesn't show on the website. Do I need to do anything else?
    It's xRetry.SpecFlow
    Andreas Willich
    @SabotageAndi
    thanks for the info, looks like something is wrong with the documentation site. I will have a look at it.
    Josh Keegan
    @JoshKeegan
    Thanks :+1:
    Andreas Willich
    @SabotageAndi
    so, documentation is fixed now
    Josh Keegan
    @JoshKeegan
    Brilliant, thanks :)
    Mark Hoek
    @mbhoek
    @SabotageAndi I see you created a separate section for DI plugins -- is it an idea to mention this in the 'Context Injection' page? https://specflow.org/documentation/Context-Injection/
    @JoshKeegan Interesting approach on testing 'Infrastructure' -- always challenging, because of timeouts and unavailability and what not. I resorted to never testing 'Infrastructure' but always mock those, but I can see the advantages of your solution.
    Josh Keegan
    @JoshKeegan
    Yeah, it can present challenges but tests using the real things prod will use is the closest you can get to certainty that everything will work :)
    Zhaopeng XUAN
    @xuanzhaopeng
    Hey mates! I take Generator plugin from Specflow-Example repo, and just overwrite public new void SetTestMethod, to add one more attribute for all tests
      "plugins": [
        {
          "name": "Allure",
          "type": "Runtime"
        },
        {
          "name": "RetryTest.Generator.SpecflowPlugin",
          "type": "Generator",
          "path": "..\\packages\\RetryTest.Generator.SpecflowPlugin.1.0.0\\build"
        }
      ],
      "stepAssemblies": [
        { "assembly": "Allure.SpecFlowPlugin" }
      ],
      "unitTestProvider": {
        "name": "nunit"
      }
    }
    here is my specflow.json with latest Specflow 3, but it seems it doesn't work when .feature.cs generated fromSpecFlow.Tools.MsBuild.Generation
    Can anyone provide an example or any idea?
    Thanks a lot
    Andreas Willich
    @SabotageAndi
    plugins aren't configured anymore in the config
    unitTestProvider is also not configured anymore in the config
    theo-vanwijk
    @theo-vanwijk
    The documentation mentioned above goes into great detail as to the creation of a NuGet package but has very little substance as to how to actually get the pulgin to work. I am trying to get a plugin to add additional custom attributes to generated tests in a .Net Core 2.1 application. I have an assembly (whatever.SpecFlowPlugin) and in that I have a class public class MySpecFlowGeneratorPlugin : IGeneratorPlugin with an attribute [assembly: RuntimePlugin(typeof(MySpecFlowGeneratorPlugin))] and in the Initialize Method I register a dependency on my implementation of IUnitTestGeneratorProvider per the documentation. I then create a reference to this assembly in my unit test assembly and can confirm the DLL is in the bin of my unit test ... but the plugin doesn't run ... what am I missing?
    Andreas Willich
    @SabotageAndi
    @theo-vanwijk You have the RuntimePlugin attribute, but implement the GeneratorPlugin. That can't work. Your plugin has to implement IRuntimePlugin if you want to have a runtimeplugin
    theo-vanwijk
    @theo-vanwijk
    @SabotageAndi I want the code generator to add an attribute to the generated test method code. Are you saying that is not done by the generator plugin?
    theo-vanwijk
    @theo-vanwijk
    I changed out the IGeneratorPlugin for a IRuntimePlugin and it still doesn't do anything
    theo-vanwijk
    @theo-vanwijk
    All of the samples seem to assume you are going to create a NuGet package, and then consume that package in your test assembly. Is there a way to get the Generator plugin to work without first generating a NuGet package?
    Andreas Willich
    @SabotageAndi
    if you want to adjust the attributes, you need a generator plugin, not a runtime plugin
    theo-vanwijk
    @theo-vanwijk
    That 2nd link was the piece I was missing. I am now working through the same Could not load file or assembly 'System.Runtime error that @HBInspiretec reported seeing. Thanks for the assist.
    theo-vanwijk
    @theo-vanwijk

    @SabotageAndi - For the Generator plugin, I've added:

    <ItemGroup>
    <SpecFlowGeneratorPlugins Include="..\<path to DLL in Generator project" />
    </ItemGroup>

    to the test project (.Net Core 2.2). I get the error below when building the test project. Any idea how to fix this pls?

    [SpecFlow] System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
    File name: 'System.Runtime, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
    at System.ModuleHandle.ResolveType(RuntimeModule module, Int32 typeToken, IntPtr typeInstArgs, Int32 typeInstCount, IntPtr methodInstArgs, Int32 methodInstCount, ObjectHandleOnStack type)
    at System.ModuleHandle.ResolveTypeHandleInternal(RuntimeModule module, Int32 typeToken, RuntimeTypeHandle[] typeInstantiationContext, RuntimeTypeHandle[] methodInstantiationContext)
    at System.Reflection.RuntimeModule.ResolveType(Int32 metadataToken, Type[] genericTypeArguments, Type[] genericMethodArguments)
    at System.Reflection.CustomAttribute.FilterCustomAttributeRecord(CustomAttributeRecord caRecord, MetadataImport scope, Assembly& lastAptcaOkAssembly, RuntimeModule decoratedModule, MetadataToken decoratedToken, RuntimeType attributeFilterType, Boolean mustBeInheritable, Object[] attributes, IList derivedAttributes, RuntimeType& attributeType, IRuntimeMethodInfo& ctor, Boolean& ctorHasParameters, Boolean& isVarArg)
    at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeModule decoratedModule, Int32 decoratedMetadataToken, Int32 pcaCount, RuntimeType attributeFilterType, Boolean mustBeInheritable, IList derivedAttributes, Boolean isDecoratedTargetSecurityTransparent)
    at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeAssembly assembly, RuntimeType caType)
    at System.Reflection.RuntimeAssembly.GetCustomAttributes(Type attributeType, Boolean inherit)
    at System.Attribute.GetCustomAttributes(Assembly element, Type attributeType, Boolean inherit)
    at System.Attribute.GetCustomAttribute(Assembly element, Type attributeType, Boolean inherit)
    at TechTalk.SpecFlow.Generator.Plugins.GeneratorPluginLoader.LoadPlugin(PluginDescriptor pluginDescriptor)

    @SabotageAndi do you know if the above issue was resolved, and if so, how? I have been reading various reports and trying a number of suggested fixes with no luck yet

    Andreas Willich
    @SabotageAndi
    @theo-vanwijk How do you build the project? With Visual Studio/msbuild or dotnet build?
    If it is Visual Studio, the build process runs in .NET Framework and not .NET Core. So the generator plugin has to be compiled for .NET Framework.
    Probably you only build it for .NET Core
    theo-vanwijk
    @theo-vanwijk
    I'm building it in the VS 2017 IDE with .Net Core 2.1 as the target framework, although I did set the framework to dotnet standard 2.0 for the plugin assembly to resolve some warnings I was getting
    theo-vanwijk
    @theo-vanwijk

    Adding .Net Framework to the build targets doesn't resolve the issue

    <PropertyGroup>
          <TargetFrameworks>netstandard2.0;netcoreapp2.1;net462</TargetFrameworks>
          <AzureFunctionsVersion>v2</AzureFunctionsVersion>
          <UseNETCoreGenerator>true</UseNETCoreGenerator>
      </PropertyGroup>

    unless there's something else I need to do?

    theo-vanwijk
    @theo-vanwijk
    If I change test assembly SpecFlowGeneratorPlugins reference to framework (net462) plugin dll, the error goes away, but the generator code never gets called :(
    clydevassallo
    @clydevassallo

    Hi. I'd like to discuss 2 things:

    1) The targets file in runtime and generator plugins has conditions for .NETCoreApp and .NETFramework. In our case, we're referencing the plugins in a .NETStandard project containing the feature files. This is causing the plugin path to be built incorrectly. Can the .NETStandard condition be added, setting the path variable to netstandard2.0 as well?

    2) I noticed that the SpecFlow.Autofac plugin is now versioned within the SpecFlow git repo. We had done some changes to the plugin to include a new attribute called 'FeatureDependencies' which can do Autofac registrations at a Feature level rather than at a Scenario level. Would you be interested in such a contribution?

    Andreas Willich
    @SabotageAndi

    About 1:
    .NET Standard for the test project is wrong. The xUnit people made a good explanation why: https://xunit.net/docs/why-no-netstandard
    We have the same view of this topic.

    About 2:
    Sure, send us the Pull Request.

    clydevassallo
    @clydevassallo

    1) Thanks for the article. However, in our case, we have 2 projects:

      - One with the step definition classes, helper classes and the class registering dependencies (using ScenarioDependencies attribute).
      - Another with feature files referencing any 'Step Definition' projects needed.

    In this scenario, I consider the test project to be the latter one and this would target .NET Core. The former project however is a class library with step definitions and I believe that can validly target .NET Standard. The former project is the one referencing the SpecFlow.Autofac plugin in our use-case. What do you think?

    2) Thanks. Will do.

    Andreas Willich
    @SabotageAndi
    having the step definition assembly .NET Standard is ok. The project with the feature files has to be .NET Core or .NET Framework.
    Ah, and the project with the steps is referencing SpecFlow.AutoFac?
    clydevassallo
    @clydevassallo
    Yep exactly. The project with step definitions is referencing SpecFlow.Autofac and wrongly attempting to find the dll in SPECFLOW_PATH/lib/Specflow.Autofac.dll rather than SPECFLOW_PATH/lib/netstandard2.0/Specflow.Autofac.dll
    Andreas Willich
    @SabotageAndi
    ok, I understand the problem.
    But I wouldn't add the condition for .NET Standard. I would put the ItemGroup at https://github.com/techtalk/SpecFlow/blob/master/Plugins/SpecFlow.Autofac.SpecFlowPlugin/build/SpecFlow.Autofac.props#L4 under a condition that it only happens for .NET Framework and .NET Core.
    This is only needed that SpecFlow finds the Runtime plugin. It's not necessary for compiling the project that references the package
    @clydevassallo Could you please open an Issue on GitHub for this.
    clydevassallo
    @clydevassallo

    If I understand correctly, this means that the copy operation will only happen if the project referencing the plugin is targeting .NET Core / .NET Framework.

    So with the proposed change:
    If the feature file project references a .NET Standard step definition project which in turn references the plugin, the plugin will not be copied to the output directory of the feature file project. On the other hand, if we have the same setup but the step definition project is a .NET Core project, it is copied automatically because of the transitive reference.

    A work around for this would be to always reference the plugin in both projects for it to be consistently copied.

    In contrast, if the condition is added to the https://github.com/techtalk/SpecFlow/blob/master/Plugins/SpecFlow.Autofac.SpecFlowPlugin/build/SpecFlow.Autofac.targets file, the plugin would be automatically copied to the output folder of our feature files project without needing the 2nd reference, regardless of the step definition project's .NET target.

    @SabotageAndi We would be able to work with both solutions but I'm thinking that adding it to the targets file would offer a more consistent behavior. Let me now what you think and in the mean time I'll be creating the GitHub issue for this.

    theo-vanwijk
    @theo-vanwijk

    If it is Visual Studio, the build process runs in .NET Framework and not .NET Core. So the generator plugin has to be compiled for .NET Framework.

    @SabotageAndi I am having trouble understanding this statement you made. My application targets .Net Core only. It cannot be running in Framework. The fact that Visual Studio uses MSBuild to compile it does not mean it is running in Framework - dotnet build is making the same calls to MSBuild that the Vistual Studio IDE is making to build a core project. Can you explain why (or point me at an article) the SpecFlow plugin cannot target Core and still run in the VS IDE?