Class ScreenplaySteps

Namespace

CSF.Screenplay

Assembly

CSF.Screenplay.SpecFlowPlugin.dll

A subclass of TechTalk.SpecFlow.Steps provided for convenience of SpecFlow 3.x users to avoid naming conflicts.

public abstract class ScreenplaySteps : Steps, IContainerDependentObject

Inheritance

object

Steps

ScreenplaySteps

Implements

IContainerDependentObject

Inherited Members

Steps.AssertInitialized()

Steps.TestRunner

Steps.ScenarioContext

Steps.FeatureContext

Steps.TestThreadContext

Steps.StepContext

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.MemberwiseClone()

object.ReferenceEquals(object, object)

object.ToString()

Remarks

In SpecFlow 3.x, the Steps class has three methods named Given, When & Then which can cause a naming conflict with the same-named methods of 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 boilerplate which spoils the ease-of-comprehension for Screenplay-based test logic. This subclass of Steps provides a workaround to that situation. Instead of deriving from the SpecFlow Steps class and including using static CSF.Screenplay.PerformanceStarter; at the top of your source file, have your bindings derive from this class instead. This provides Given, When, Then methods which have the same functionality as those in PerformanceStarter but in a manner which will not cause a name-resolution conflict.

Note that in SpecFlow 4.x and up, this problem is irrelevant; there is no gain in using this subclass over the using static technique. As noted here https://docs.specflow.org/projects/specflow/en/latest/Bindings/Calling-Steps-from-Step-Definitions.html and here https://github.com/SpecFlowOSS/SpecFlow/issues/1733 the Give, When & Then methods upon the SpecFlow Steps 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.

Methods

Given(Actor)

Returns the actor instance, as an ICanPerformGiven, in order to perform precondition actions.

public static ICanPerformGiven Given(Actor actor)

Parameters

actor Actor

The actor.

Returns

ICanPerformGiven

Remarks

This method is equivalent to Given(Actor) but is provided as a convenience method in a subclass of TechTalk.SpecFlow.Steps to avoid method-name resolution conflicts. See the remarks on ScreenplaySteps for more info.

Then(Actor)

Returns the actor instance, as an ICanPerformThen, in order to get information which are required to make assertions that the scenario has completed successfully.

public static ICanPerformThen Then(Actor actor)

Parameters

actor Actor

The actor.

Returns

ICanPerformThen

Remarks

This method is equivalent to Then(Actor) but is provided as a convenience method in a subclass of TechTalk.SpecFlow.Steps to avoid method-name resolution conflicts. See the remarks on ScreenplaySteps for more info.

When(Actor)

Returns the actor instance, as an ICanPerformWhen, in order to perform actions which exercise the system under test.

public static ICanPerformWhen When(Actor actor)

Parameters

actor Actor

The actor.

Returns

ICanPerformWhen

Remarks

This method is equivalent to When(Actor) but is provided as a convenience method in a subclass of TechTalk.SpecFlow.Steps to avoid method-name resolution conflicts. See the remarks on ScreenplaySteps for more info.