Liskov Substitution Principle: keeping the Abilities separate from Interactions allows us to not only bridge the bound domain context in an elegant way, but also substitute one authentication strategy for another.Instead we’d create an AuthenticateWithOpenId Ability and a Task to LogInWithOpenId Open/Closed Principle: If we needed to authenticate using a different mechanism, say OpenId for instance, we wouldn’t have to change the custom Actor class as in the inheritance-based example.Single Responsibility Principle: The Actor, Authenticate and LogIn classes each have a single responsibility.The advantage of this approach is that it complies with the SOLID principles: Actor Ī call to the authenticated(actor) method retrieves the Actor’s ability to Authenticate, and with it, the username and password needed for Aurelia to log in. To solve the problem using inheritance we can extend and build on the Screenplay Actor class, adding any additional methods and data we need: class RegisteredUser extends. Having said that, if we needed to be a bit more strict about what Actors can and cannot do in our acceptance tests, we could model those constraints using Abilities. It’s not a hard constraint that could be verified at either compile or runtime, but neither it’s intended to be. Of course, giving an Actor a name associated with their persona serves indicative purposes only. This makes it easier not only to distinguish one Actor from another, but more importantly - to spot logical errors in the tests: “Hey, why is Aurelia the Author touching the admin panel?” Here we’re giving our Actors names that sound similar to the name of the Role they perform. Let’s look into this in more detail.Ĭonsider the following example: Actor aurelia = Actor.named("Aurelia") // Aurelia, the Author Actor edward = Actor.named("Ed") // Ed, the Editor Actor adam = Actor.named("Adam") // Adam, the Administrator The reason why we tend to model our Actors as separate entities and associate them with distinct personas, is also the reason why Actors have names. In the Screenplay Pattern, an Actor represents either a person or an external system verifying and interacting with the system we’re testing. Would these roles each have dedicated Actors? Or would I rather create Abilities that can reach those sections and assign them to generic Actors as needed? author, editor, admin) and can see different sections of the webpage. I have a system where users can have different roles (e.g.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |