Resolve #238 - Update docco to refer to Reqnroll

Author: craigfowler

.vscode/settings.json

@@ -1,4 +1,7 @@
 {
-    "cucumberautocomplete.steps": [ "Tests/CSF.Screenplay.SpecFlow.Tests/StepDefinitions/**/*.cs" ],
+    "cucumberautocomplete.steps": [
+        "Tests/CSF.Screenplay.SpecFlow.Tests/StepDefinitions/**/*.cs",
+        "Tests/CSF.Screenplay.Reqnroll.Tests/StepDefinitions/**/*.cs"
+    ],
     "cucumberautocomplete.strictGherkinCompletion": true,
 }

CSF.Screenplay.Docs/docs/bestPractice/SuitabilityAsATestingTool.md

@@ -1,15 +1,15 @@
 # Where Screenplay is suitable for testing
 
 The Screenplay pattern is a recommended tool for writing automated tests for application software.
-Unlike [NUnit] or [SpecFlow] (or many others) Screenplay is not a complete testing framework.
+Unlike [NUnit] or [Reqnroll] (or many others) Screenplay is not a complete testing framework.
 Rather, Screenplay integrates with your chosen testing framework to assist in the writing of test logic.
 
 _Screenplay is not a silver bullet_; some kinds of tests could benefit from Screenplay and others will not.
 Some testing scenarios are listed below, along with a brief consideration as to whether Screenplay is likely to be relevant.
 Terminology can differ between developers, so each type of test begins with a short definition.
 
 [NUnit]: https://nunit.org/
-[SpecFlow]: https://specflow.org/
+[Reqnroll]: https://reqnroll.net/
 
 ## Ideal: System tests
 
@@ -65,6 +65,6 @@ This is particularly true if the test/sample scenarios would be recognisable to
 ## Recommended: Use BDD-style tests
 
 Screenplay is a great tool when used alongside [Behaviour Driven Development] (BDD).
-Whilst the use of a BDD framework such as [SpecFlow] is not at all mandatory, those familiar with BDD will quickly see the synergies with Screenplay.
+Whilst the use of a BDD framework such as [Reqnroll] is not at all mandatory, those familiar with BDD will quickly see the synergies with Screenplay.
 
 [Behaviour Driven Development]: https://en.wikipedia.org/wiki/Behavior-driven_development

CSF.Screenplay.Docs/docs/bestPractice/WritingTests.md

@@ -11,7 +11,7 @@ Rather than using many performables at the top-level of your tests, create [high
 When using a method-driven testing framework, such as NUnit, five performables in a single test method is a reasonable number.
 More than approximately ten performables is too many.
 
-When using a binding-driven testing framework like SpecFlow, each binding should ideally correspond to at-most one performable.
+When using a binding-driven testing framework like Reqnroll, each binding should ideally correspond to at-most one performable.
 
 [performables]: ../../glossary/Performable.md
 [high-level tasks]: ../../glossary/Task.md

CSF.Screenplay.Docs/docs/dependencyInjection/InjectingServices.md

@@ -17,13 +17,13 @@ Which of these depends upon the nature and paradigm of the test framework.
 For frameworks which are based on **test methods** such as [NUnit], services are typically injected via _method parameter injection_ into the test methods.
 [If Screenplay were to be extended] to work with frameworks such as xUnit or MSTest then this is likely to be the technique used.
 
-For frameworks which are based on **binding classes** such as [SpecFlow], services are constructor-injected into binding classes.
+For frameworks which are based on **binding classes** such as [Reqnroll], services are constructor-injected into binding classes.
 
 Use dependencies injected in this way to get access to [commonly-used Screenplay services] and anything else required at the root level of your test logic.
 
 [NUnit]: https://nunit.org/
 [If Screenplay were to be extended]: ../extendingScreenplay/TestIntegrations.md
-[SpecFlow]: https://specflow.org/
+[Reqnroll]: https://reqnroll.net/
 [commonly-used Screenplay services]: InjectableServices.md
 
 ## Into standalone performance logic

CSF.Screenplay.Docs/docs/extendingScreenplay/TestIntegrations.md

@@ -1,11 +1,11 @@
 # Writing new Test framework integrations
 
 A way in which Screenplay is available for extension is the integration of Screenplay with other Test frameworks.
-Screenplay currently ships with integrations for [NUnit] and [SpecFlow] but developers are free to integrate it into other frameworks if they wish.
+Screenplay currently ships with integrations for [NUnit] and [Reqnroll] but developers are free to integrate it into other frameworks if they wish.
 Developers who are interested in this may use the source code to these two integrations as inspiration.
 
 [NUnit]: https://nunit.org
-[SpecFlow]: https://specflow.org
+[Reqnroll]: https://reqnroll.net/
 
 ## Requirements
 
@@ -33,7 +33,7 @@ Terminologies differ between testing frameworks; the word [Scenario] is used to
     * Failure to do this could lead to memory leaks or unnecesarily high resource usage whilst the [Screenplay] is in-progress
 * The test framework **must** provide access to at least the [`ICast`] and [`IStage`], resolved from the [Scenario]'s dependency injection scope, to the [Scenario] logic
     * The manner of doing this depends entirely on the test framework
-    * By way of example, in NUnit this is performed by providing the values of parameters to the test method, in SpecFlow this is performed by resolving step bindng classes from that same DI scope, allowing constructor injection
+    * By way of example, in NUnit this is performed by providing the values of parameters to the test method, in Reqnroll this is performed by resolving step bindng classes from that same DI scope, allowing constructor injection
 
 [`Screenplay`]: xref:CSF.Screenplay.Screenplay
 [Scenarios]: ../../glossary/Scenario.md

CSF.Screenplay.Docs/docs/gettingStarted/reqnroll/index.md

@@ -1,25 +1,33 @@
-# Screenplay & SpecFlow tutorial
+# Screenplay & Reqnroll tutorial
 
-Begin writing SpecFlow tests using Screenplay by following these steps.
+> [!TIP]
+> Are you using the legacy **SpecFlow**?
+> **Reqnroll** is the maintained fork of SpecFlow, so it's recommended you upgrade your projects ASAP.
+>
+> For now, CSF.Screenplay continues to support SpecFlow.
+> Use the [CSF.Screenplay.SpecFlow] package and SpecFlow v3.4.3 or higher instead.
+> The remainder of the instructions below work for either Reqnroll or SpecFlow.
+
+Begin writing Reqnroll tests using Screenplay by following these steps.
 Further detail is provided below.
 
-1. Ensure that your test project uses [SpecFlow version 3.4.3] or higher
-1. Install the NuGet package **[CSF.Screenplay.SpecFlow]** to the project which will contain your `.feature` files
-1. _Optional:_ Add services to dependency injection which will be required by the [Abilities] you intend to use.  If required, [use SpecFlow context injection & hooks] to add these to the DI container.
+1. Ensure that your test project uses [Reqnroll version 2.0.0] or higher
+1. Install the NuGet package **[CSF.Screenplay.Reqnroll]** to the project which will contain your `.feature` files
+1. _Optional:_ Add services to dependency injection which will be required by the [Abilities] you intend to use.  If required, [use Reqnroll context injection & hooks] to add these to the DI container.
 1. Write step binding classes which dependency-inject and use Screenplay's architecture
 
-[SpecFlow version 3.4.3]: https://www.nuget.org/packages/SpecFlow/3.4.3
-[CSF.Screenplay.SpecFlow]: https://www.nuget.org/packages/CSF.Screenplay.SpecFlow
+[Reqnroll version 2.0.0]: https://www.nuget.org/packages/Reqnroll/2.0.0
+[CSF.Screenplay.Reqnroll]: https://www.nuget.org/packages/CSF.Screenplay.Reqnroll
 [Abilities]: ../../../glossary/Ability.md
-[use SpecFlow context injection & hooks]: https://docs.specflow.org/projects/specflow/en/latest/Bindings/Context-Injection.html#advanced-options
+[use Reqnroll context injection & hooks]:https://docs.reqnroll.net/latest/automation/context-injection.html#advanced-options
 
 ## Writing step bindings
 
 > [!IMPORTANT]
-> When using SpecFlow with Screenplay, every Screenplay-using test within a test assembly (thus, within a .NET project) must share the same instance of `Screenplay`.
+> When using Reqnroll with Screenplay, every Screenplay-using test within a test assembly (thus, within a .NET project) must share the same instance of `Screenplay`.
 > This is not expected to be problematic, as all the [`Screenplay`] object does is set-up the Screenplay architecture and dependency injection for the tests.
 
-When using Screenplay with SpecFlow, `.feature` files are written as normal.
+When using Screenplay with Reqnroll, `.feature` files are written as normal.
 The only difference in writing your tests is that **Step Binding** classes should inject Screenplay architecture and use it within the bindings. 
 
 The recommended services to inject into your step binding classes are either [`IStage`] or [`ICast`].
@@ -38,7 +46,7 @@ If you are not using Personas to get actors, then you might also need to inject
 > The implied ability, the performables, persona and `DishwashingBuilder` used in this test, related to washing dishes, are all fictitious.
 > See [the documentation for writing performables] to learn about how these could be written.
 
-This example assumes that SpecFlow is writting using [the NUnit runner], and thus [it makes use of NUnit-style assertions].
+This example assumes that Reqnroll is writting using [the NUnit runner], and thus [it makes use of NUnit-style assertions].
 Feel free to replace the assertion _with whichever assertion library you wish to use_.
 
 ```csharp
@@ -75,5 +83,5 @@ public class WashTheDishesSteps(IStage stage)
 ```
 
 [the documentation for writing performables]: ../../writingPerformables/index.md
-[the NUnit runner]: https://docs.specflow.org/projects/specflow/en/latest/Installation/Unit-Test-Providers.html
+[the NUnit runner]: https://docs.reqnroll.net/latest/integrations/nunit.html
 [it makes use of NUnit-style assertions]: https://docs.nunit.org/articles/nunit/writing-tests/assertions/assertion-models/constraint.html

CSF.Screenplay.Reqnroll/ScreenplayBinding.cs

@@ -9,7 +9,7 @@
 namespace CSF.Screenplay
 {
     /// <summary>
-    /// SpecFlow binding which uses hooks to coordinate the relevant <see cref="Screenplay"/> &amp; <see cref="IPerformance"/> event invokers.
+    /// Reqnroll binding which uses hooks to coordinate the relevant <see cref="Screenplay"/> &amp; <see cref="IPerformance"/> event invokers.
     /// </summary>
     [Binding]
     public class ScreenplayBinding

CSF.Screenplay.Reqnroll/ScreenplayPlugin.cs

@@ -18,15 +18,15 @@
 namespace CSF.Screenplay
 {
     /// <summary>
-    /// The Screenplay plugin for SpecFlow.
+    /// The Screenplay plugin for Reqnroll.
     /// </summary>
     /// <remarks>
     /// <para>
-    /// This plugin class is the <xref href="IntegrationGlossaryItem?text=test+framework+integration"/> for SpecFlow.
-    /// Crucially it adds the Screenplay architecture to the SpecFlow architecture.
+    /// This plugin class is the <xref href="IntegrationGlossaryItem?text=test+framework+integration"/> for Reqnroll.
+    /// Crucially it adds the Screenplay architecture to the Reqnroll architecture.
     /// </para>
     /// <para>
-    /// Becuase this plugin leverages the SpecFlow/BoDi <c>IObjectContainer</c>, it is likely incompatible with other plugins
+    /// Becuase this plugin leverages the Reqnroll/BoDi <c>IObjectContainer</c>, it is likely incompatible with other plugins
     /// which integrate with third party Dependency Injection libraries.
     /// </para>
     /// <para>
@@ -38,8 +38,8 @@ namespace CSF.Screenplay
     /// <para>
     /// If you wish to further customise the dependency injection, such as adding injectable services for <xref href="AbilityGlossaryItem?text=abilities"/>
     /// or implementations of <see cref="IPersona"/>, add them to the relevant DI container.
-    /// When using SpecFlow's default BoDi container this is described in the following article
-    /// <see href="https://docs.specflow.org/projects/specflow/en/latest/Bindings/Context-Injection.html#advanced-options"/>.
+    /// When using Reqnroll's default BoDi container this is described in the following article
+    /// <see href="https://docs.reqnroll.net/latest/automation/context-injection.html#advanced-options"/>.
     /// If using a third-party DI container then you should use that container's appropriate mechanism of adding services.
     /// </para>
     /// </remarks>
@@ -56,8 +56,9 @@ public class ScreenplayPlugin : IRuntimePlugin
         /// </summary>
         /// <remarks>
         /// <para>
-        /// This is required because the bindings for beginning/ending the Screenplay in <see cref="ScreenplayBinding"/> must be <c>static</c>:
-        /// <see href="https://docs.specflow.org/projects/specflow/en/latest/Bindings/Hooks.html#supported-hook-attributes"/>.
+        /// This is required because the bindings for beginning/ending the Screenplay in <see cref="ScreenplayBinding"/> must be <c>static</c>.
+        /// Those bindings use the <c>[BeforeTestRun]</c> and <c>[AfterTestRun]</c> hooks, which must be static, as documented here:
+        /// <see href="https://docs.reqnroll.net/latest/automation/hooks.html#supported-hook-attributes"/>
         /// </para>
         /// </remarks>
         static public Screenplay Screenplay { get; private set; }
@@ -88,9 +89,10 @@ static void OnConfigurationDefaults(object sender, ConfigurationDefaultsEventArg
         /// </summary>
         /// <remarks>
         /// <para>
-        /// It is a known/documented issue that this event may be triggered more than once in a single run of SpecFlow:
-        /// <see href="https://github.com/techtalk/SpecFlow/issues/948"/>, and by more than one thread.
-        /// Thus, to prevent double-initialisation, this method occurs in a thread-safe manner which ensures that even if it
+        /// It was a known/documented issue that this event may be triggered more than once in a single run of the old
+        /// SpecFlow, and by more than one thread.  Unfortunately I don't know if that's still applicable in Reqnroll.
+        /// I've opened this discussion to see if I can find out: <see href="https://github.com/orgs/reqnroll/discussions/1005"/>.
+        /// To prevent double-initialisation, this method occurs in a thread-safe manner which ensures that even if it
         /// is executed more than once, there is no adverse consequence.
         /// </para>
         /// </remarks>

CSF.Screenplay.Reqnroll/ScreenplaySteps.cs

@@ -1,9 +1,6 @@
-using CSF.Screenplay.Actors;
-#if SPECFLOW
+#if SPECFLOW
+using CSF.Screenplay.Actors;
 using TechTalk.SpecFlow;
-#else
-using Reqnroll;
-#endif
 
 namespace CSF.Screenplay
 {
@@ -12,6 +9,9 @@ namespace CSF.Screenplay
     /// </summary>
     /// <remarks>
     /// <para>
+    /// Note that this class does not exist in the Reqnroll Test Framework Integration.  It is irrelevant there.
+    /// </para>
+    /// <para>
     /// In SpecFlow 3.x, the <c>Steps</c> class has three methods named <c>Given</c>, <c>When</c> &amp; <c>Then</c> which can cause
     /// a naming conflict with the same-named methods of <see cref="PerformanceStarter"/>.  If you using the performance starter in
     /// the recommended way, then the methods of these two types can become ambiguous and force the developer to write additional
@@ -22,13 +22,10 @@ namespace CSF.Screenplay
     /// but in a manner which will not cause a name-resolution conflict.
     /// </para>
     /// <para>
-    /// Note that in SpecFlow 4.x and up, this problem is irrelevant; there is no gain in using this subclass over the <c>using static</c> technique.
-    /// As noted here <see href="https://docs.specflow.org/projects/specflow/en/latest/Bindings/Calling-Steps-from-Step-Definitions.html"/>
-    /// and here <see href="https://github.com/SpecFlowOSS/SpecFlow/issues/1733"/> the Give, When &amp; Then methods upon the
-    /// SpecFlow <c>Steps</c> class were removed in v4.x. This means that the naming conflict won't be present and that there is no need
-    /// for your bindings to derive from this class instead of the official Steps class.
-    /// Indeed, Screenplay could be described as a specific implementation of the 'driver pattern', which is noted in the linked Github issue
-    /// as a best-practice alternative to calling-steps-from-steps.
+    /// Note that in SpecFlow 4.x and up, and Reqnroll, this problem is irrelevant; there is no gain in using this subclass over the <c>using static</c> technique.
+    /// The Given, When &amp; Then methods upon the SpecFlow <c>Steps</c> class were removed in v4.x, and never existed in any version of Reqnroll.
+    /// This means that the naming conflict won't be present and that there is no need for your bindings to derive from this class instead
+    /// of the official Steps class.
     /// </para>
     /// </remarks>
     public abstract class ScreenplaySteps : Steps
@@ -75,3 +72,4 @@ public abstract class ScreenplaySteps : Steps
         public static ICanPerformThen Then(Actor actor) => PerformanceStarter.Then(actor);
     }
 }
+#endif

CSF.Screenplay.Reqnroll/ServiceCollectionAdapter.cs

@@ -12,7 +12,7 @@
 namespace CSF.Screenplay
 {
     /// <summary>
-    /// Adapter class which allows a SpecFlow/BoDi <c>IObjectContainer</c> to be used as an <see cref="IServiceCollection"/>.
+    /// Adapter class which allows a Reqnroll/BoDi <c>IObjectContainer</c> to be used as an <see cref="IServiceCollection"/>.
     /// </summary>
     /// <remarks>
     /// <para>
@@ -68,7 +68,7 @@ public ServiceDescriptor this[int index]
         /// is <see cref="ServiceLifetime.Scoped"/> then the service descriptor will not be added and will be silently ignored.
         /// </para>
         /// <para>
-        /// In reality, the Specflow BoDi object container only really supports singleton services at this level. So, any services added as
+        /// In reality, the Reqnroll BoDi object container only really supports singleton services at this level. So, any services added as
         /// <see cref="ServiceLifetime.Transient"/> will actually become singletons here. Whilst the BoDi container does support scoped services, they
         /// must be added directly to the scope instance and cannot be added in advance.
         /// </para>