How does this compare to Boa.Constrictor?

[LarsKemmann]

I'm just starting to learn about Screenplay, BDD, Reqnroll, etc., and would greatly appreciate some guidance. What questions should I be asking?

https://github.com/q2ebanking/boa-constrictor/

[craigfowler]

Well, firstly, welcome on your journey to writing better tests!

Right now, CSF.Screenplay is undergoing a rewrite and is probably not ready for prime time/prod usage. v1 supports .NET Framework only and v2 is not quite ready to go to prod yet. There's also the usual "I can do better than that, now", which is typical for all devs, I guess. It's also not a full-time project for me; I don't get to work on it at my day job. BC is definitely a more mature implementation and if you want something for production today then I would hand-on-heart recommend that over CSF.Screenplay.

Certainly, Boa Constrictor and CSF.Screenplay are both implementations of the Screenplay pattern. You're going to see a lot of architectural similarities, not because we've been reading one another's code (I was barely aware of BC and I doubt any of those devs have heard of me) but because we're building to the same conceptual standard.

I've had a skim of BC and - at a glance - things I notice which differ are...

Use of Dependency Injection frameworks

Boa Constrictor does not make use of any dependency injection frameworks. Depending upon your tastes as a developer, this could be considered either good or bad. It's good because "what you see is what you get" and it's blindingly obvious where every object/value/parameter comes from just from reading code.

On the downside, I've found it tends to lead to more boilerplate code, written manually. I also found that it increases the resistance to adding cross-cutting concerns like reporting or saving assets. I was somewhat 'inspired' when I saw Reqnroll (formerly SpecFlow) which does have a DI container built in. At that point I stopped believing that "DI containers in test code is forbidden" and added it to my Screenplay impl. I'm even less worried about DI in tests, since Microsoft created the baseline Microsoft.Extensions.DependencyInjection.Abstractions package. That's really changed the ecosystem in that so many libraries, by default, assume that you're going to integrate them via an .AddXyz() extension method for an IServiceCollection.

Reporting

From the quick skim I have seen on BC, it doesn't do reporting in the way that CSF.Screenplay does. At the end of any Screenplay, CSF Screenplay will (unless you disable it) write a JSON-formatted report of every performance in that Screenplay. CSF.Screenplay also includes a commandline app which can convert that JSON report into a human-readable HTML document. I'm in the process of improving that functionality right now.

That said, I do see the infrastructure at https://github.com/q2ebanking/boa-constrictor/tree/main/Boa.Constrictor.Screenplay/Logging/Loggers and that's pretty good, especially given there's no DI framework.

CSF.Screenplay's reporting is far more structured, probably because it has the benefit of a DI container at its core. BC writes "begin doing" and "finishes doing" messages into its logs, so it's clear where the scope of a performable (I think IInteraction in their terminology) begins and ends. CSF.Screenplay writes only one message per performable, but any performables spawned within are structurally saved into the report as children.

Direct test framework integration

I see some minimal XUnit integration in BC. I've written a Reqnroll integration, which also works for legacy SpecFlow, for now. It's in Reqnroll's native plugin format. I've done the same for NUnit. In theory, from what I know of XUnit, it shouldn't be too difficult to write one for XUnit either, although I'm not an XUnit expert, so it's not high on my own priority list.

BC is very neutral to test frameworks. Thus the consuming dev is responsible for the scaffold which sets up a test. Compare https://q2ebanking.github.io/boa-constrictor/tutorial/part-2-web-ui-testing/#10-refactoring-the-project (a relatively minimal sample NUnit test) with https://csf-dev.github.io/CSF.Screenplay/docs/gettingStarted/nunit3/index.html#writing-test-methods, which is a conceptually similar example.

CSF.Screenplay can totally be used standalone without any integration library (say you were integrating it into your own app, for something besides tests) and in that sense BC can be too.

Cast & Stage support

I don't see BC implementing the Cast or the Stage anywhere. I don't think they're strictly part of the Screenplay pattern, so that's not wrong of it. The Cast & Stage (and Personas, for that matter) are great tools for managing performances which include multiple actors, or dealing with well-known actors with pre-configured sets of abilities.

I think that BC would support a test (or scenario, or performance, depending on your terminology) which uses multiple actors because they're independent and (with no DI framework) they would consume no shared resources. Each would need to be constructed and scaffolded by hand. CSF.Screenplay uses the cast (or stage) for this, and (if you're using personas too) you write a single line like var jane = cast.GetActor<Jane>();. In this example, Jane is a class which is the IPersona which creates & configures the well-known actor named "Jane". That line either fetches an existing instance of that actor (if they have already been created for the current test) or it creates them using the Persona class, caches them for the lifetime of the test and returns them.

I found when using Reqnroll, which is based on bindings and step definitions, the Stage was far more useful than the Cast. That's because with the stage you can have a Reqnroll step definition bound to a Gherkin regex like "s?he adds eggs to (?:his|her) shopping cart" and the stage is tracking a concept of "the current actor". Thus each step definition can be used for any actor without needing to name them every time.

Extensibility

I've had a look through BC's core code and I'm impressed with their architecture: it's not based on lots of abstract base classes (one of my mistakes in v1). Everything is very clean and based on single responsibility interfaces, which is the same as CSF.Screenplay v2. So, if you wanted to write new tasks (compositions of other tasks) then it would be really easy to do so.

Playwright support

BC already has it, I plan on adding it to CSF.Screenplay at some point, but it's not started yet.

RestSharp support

BC supports RestSharp directly. CSF. Screenplay has https://csf-dev.github.io/CSF.Screenplay/docs/extensions/webApis/index.html which is a micro-framework for framing API requests in a manner that follows the Screenplay patterns. They're conceptually the same thing but obviously their syntax will differ, and I'd bet my lunch money that RestSharp will be far more full-featured.

[LarsKemmann]

@craigfowler This was incredibly helpful, thank you! Since I'm early in my journey into test engineering, I think I'm okay with something that isn't production-ready yesterday. 😊 Do you have a sense of when the v2 rewrite will be in a consumable-alpha stage that's usable by interested (but not deeply Screenplay-trained) early adopters?

[craigfowler]

Do you have a sense of when the v2 rewrite will be in a consumable-alpha stage

How about "today"?

I have shuffled the roadmap around. I also just noticed that the roadmap was unintentionally configured with private visibility, so I fixed that too. I've just finished off #260 and #254 which means that packages are created and published on each CI build (to Github's NuGet feed) and on each version-numbered tag (to nuget.org).

I've just tagged release 2.0.0-5.alpha which is an alpha release of the packages. In the next few minutes those should all appear on public NuGet for consumption.

Hints to get started

As is (at least, it is now) visible on the roadmap, the next things on the list are #365, #71 and #225. If you're interested in Screenplay for BDD then I presume you're interested in Reqnroll & Selenium? The Getting Started guide for Reqnroll & Screenplay is your starting point for the scaffold.

Setting up DI in Reqnroll

I noticed that the docco I wrote is a little light on telling you how to set up DI, which is what #365 is all about. It directs you to Reqnroll's context injection and BeforeScenario hook but doesn't tell you how or why you should care about this; my bad. As a hint for getting started, your use of that technique might look something like this:

using CSF.Screenplay;
using CSF.Screenplay.Selenium;

[Binding]
public class DependenciesSetup(IObjectContainer reqnrollContainer)
{
    [BeforeScenario]
    public void AddExtraDependencies()
    {
        reqnrollContainer.ToServiceCollection()
            .AddSelenium()
            // You want fries with that?  Add any further DI registrations here
            ;
    }
}

That adds the scaffold for Selenium into the dependency chain for Reqnroll. In this same "extra dependencies" method you'd add any registrations required for abilities, personas and the like. Note that .AddScreenplay() is already added by the Reqnroll plugin, it assumes you want that if you installed the plugin 😄 .

Adding other dependencies

For info on what adding personas etc looks like (until I write a sample project in #71) you can take a look at the DI setup for the Screenplay & Selenium unit tests. That's written in NUnit syntax (an impl of the IGetsScreenplay interface, which is not used for Reqnroll) but you'll see it has a service collection were things are added. The highlighted range is (in principle) the part which can be used for Reqnroll.

Getting WebDrivers

Lastly, this whole thing makes use of another (small) project of mine: https://github.com/csf-dev/CSF.Extensions.WebDriver. This provides a way to configure WebDrivers, if you're OK using the Microsoft Options Pattern. In that NUnit-style tests code linked above, I make use of this with the method named GetConfiguration(). That states that I have an appsettings.json file present, which has my WebDriver config inside. You can see that same file in the root of the project. I've got a few browser configs in there, including some with custom factories, but a minimal config might look like:

{
    "WebDriverFactory": {
        "DriverConfigurations": {
            "DefaultChrome": { "DriverType": "ChromeDriver" }
        },
        "SelectedConfiguration": "DefaultChrome"
    }
}

What the factory & config is there for is that it allows me to:

• Keep multiple browsers configured, so that different actors in the same Performance can use different browsers (by name)
• Switch between the default config using an environment variable or command-line switch
  • I use this technique in my cross-browser-testing GH Action, to switch the WebDriver config to use BrowerStack.
  • The MS Options/Configuration framework combines the JSON with the environment variable and allows me to override the default in the config file with a different choice

However, if you don't need any of that, then feel free to just use a minimal config, or to hard-code some config.