-
Notifications
You must be signed in to change notification settings - Fork 0
ScreenplayInTheTestingStack
The Screenplay framework is developed separately to any testing frameworks, it integrates with them via their own respective plugin-based hooks. Indeed, whilst Screenplay provides integrations for NUnit and SpecFlow out of the box, it is possible to write integrations for other test frameworks.
Include a layer diagram here showing where Screenplay lives relative to the test frameworks and external dependencies.
Let's consider the three common types of tests (along with some brief definitions).
Acceptance tests test the full application with no test fakes involved. The tests interact with the application in the same way a real user would. These are also known as "end to end" tests.
Acceptance tests are the ideal candidate for Screenplay test logic.
Integration tests exercise a number of real class implementations together. There may or may not be some test fakes involved too. The test and expected outcome should make sense to a non-developer even if the test makes use of parts of the API which are not directly exposed to real users.
You should consider whether Screenplay is suitable for this type of test. In some projects it is, in others it is not.
Unit tests work with just a single class, anything outside the class under test is replaced with a test fake. Because the test and the expected outcomes are isolated to the behaviour of a single class, they might not immediately make sense to a non-developer.
Screenplay is not recommended for unit testing; it offers little benefit to this style of test.
Screenplay lives at the level in which you would write the body of your test code. Integrations presently exist for both NUnit & SpecFlow. Screenplay's architecture allows test framework plugins to provide integrations with other testing backends.
In an NUnit-based test, the full Screenplay logic would appear immediately within the test method. The test code would consist of invoking a number of Screenplay tasks, typically finishing with one which returns a value from the software under test (the test result). The test ends with a normal assertion against that result.
With a SpecFlow test, each SpecFlow binding would typically execute a single Screenplay task. When using Screenplay and SpecFlow together, it's normal for your tasks and your bindings to maintain a (mostly) one-to-one relationship. Assertions should live outside of the Screenplay tasks, within the bindings.