Should scenarios be short or complete?

Question

Assuming the following scenario:

Scenario: A not logged in user must be able to register
    Given a non-logged in user
    When filling the registration form with full name Pepe Roni, email peperono@gmail.com, and password abcd
    Then User logs in and receive and confirmation email
    and his role is of non-premium and a notification is sent to the administrator
    and his email status is set to not verified and analytics receives such event.

Personally speaking I think that this is too long for just an scenario, however all these features must be checked as part of the requirement.

What would an ideal way of doing it?

Leaving it as is, or splitting into different scenarios?

Answer 1

Break it up.

Just as importantly, however, see what unit and integration tests you can make.

I see:

• confirmation form validations
• composition of email to a new user
• triggering email for a new user
• triggering of notifications to Administrator
• setting email status based on event
• trigger of analytics notification

All of these should have unit tests to check the functionality of the code involved, however actual dependencies should be mocked and stubbed.

Integration tests should then test these dependencies, but without using the UI because the UI is slow and brittle.

After Unit and Integration, you should try to think what is the fewest number of end to end tests and what do they need to test. Most if not all of the UI tests should be automated and part of CI/CD processes.
Add to this production monitoring, Canary releases, AB testing, BlueGreen deployment and many other aspects for a modern development environment.

It is very hard to get out of the long-established, and often seen as 'common sense' approach to test everything in the final product UI., Studying the Agile Testing Pyramid shows the way.

Answer 2

To answer to the main question: Both. Short, complete and test only thing. Avoid doing checks in different parts in the same test(check email + check back-end + check front-end)

The first issue I see its the whey the scenario is defined (too many details, not following the BDD principles -> one of them is to define steps that are very easy to understand and they don't talk about ui, when is defined to set a precondition: i am on some page, i have some data -> used if needed)

Does not seem very clear if the notifications are sent after registration or after login or if the user needs to confirm the email to complete te registration or not.

Scenario: Some meaningful name
   Given I have some state
   When I do some actions
   Then the expected results are met

Short example based on your case using api:

Scenario: New user registration sends notification to the administrator
  When I create a new user -> create user via api
  Then the administrator receives a notification -> check notification via api

Short example using ui:

Scenario: New user registration sends notification to the administrator
 Given I am on the registration page
 When I register with a new user -> generate data dynamically and does registration
 And I login with the new user -> logs in with data from registration saved in a variable
 Then the administrator receives a notification -> does the validation(via api if you check some email inbox)

What I would do

1. Identify tests by steps and one expected outcome
2. Define each test in a simple way without thinking to much to details
3. See what makes sense to have in UI and what not (more integration > less ui)
4. When implementing UI tests make sure you use some fast methods to do the setup (for example when you need a new user don't go trough the ui each time)
5. Combine validation only when makes sense, for example if you check multiple things in the same place, for example in the same email or in the same response

If you do something and seems to complicated or hard to understand => then you are doing something wrong. You should be able to understand what you define a yesr from now, also using BDD should allow anyone to understand

Answer 3

It is a good approach to split the complex scenarios in a set of short testcases.

You can use the below-mentioned use-cases for your problem, that we will usually create for functional testing services in our software testing services company.

1. Verify that new user/non-logged user should be prompted for the registration.

2. Verify that new user should be able to logged in application interface after completing the Registration form,

3. Verify that confirmation mail should be triggered to new user after completing the registration form.

4. Verify that notification mail should be triggered to administration after completing the registration form by any new user.

5. Verify that email status for new user should remain in Not Verified unless user have click on the conformation email.

6. Verify that user confirmation event should be recorded in analytics once user clicked on the conformation email.