Where to state test data in Cucumber

Question

I'm struggling to understand the best place to place test data in Cucumber scenarios.

My scenario reads like the following:

Scenario: Register member for first time
Given I have navigated to new registration page as a member who has never registered for MOS
When I complete the registration form
Then I am navigated to the registration complete page

I have my test data for the When step hard coded down in the step defs as I see it as unnecessary noise for the feature file. I posted another post about if this is the best place for this and I am now looking into creating a properties file to store such data.

The problem with this scenario is that once I have used this particular data for this test it effectively doesn't work for this test any longer. This being because the member is now in a registered state rather than unregistered which drives different UI behavior.

I know the ideal fix here is for my Given step to perhaps delve into the source system and locate some test data that works for the test but source system is not web (no selenium) and we are restricted on db access so that rules that option out.

I'm wondering if anyone has run into similar challenges and what possible ways around this situation we may have?

At the moment I will have a spreadsheet (.properties) that will feed data into the step def but once that test has been run once then someone will have to refresh that spreadsheet data with a member that works (unregistered member). Messy, brittle, horrible!

Answer 1

In my opinion you can use 4 approaches:

1. Create/append a unique ID for every user you create (with something like String uniqueID = UUID.randomUUID().toString();)
2. Create/append an index, to be stored in a file, to the used ID (so that you will have users like "User_1", "User_2" and so on)
3. Create/append a timestamp to the user ID to be used
4. Go to the developers and ask for a way to programmatically delete the data that you just created. The system MUST be adapted to be testable otherwise we will always have these issues and we will only have local improvements. Quality is a responsibility for everyone in the team.

I'd say you can use one of the first 3 approaches as a temporary solution while the 4th one is waiting to be ready.

Answer 2

Your given step should include code that sets up the test state that the rest of the code expects. If this is difficult to orchestrate then it hints at your application having potential deployment and migration issues. You might also find that contract testing (see pact) can help you avoid lengthy and expensive end to end testing by allowing you to compare consumer and provider interfaces in isolation.

Answer 3

For data setup, we implemented as delete SQL script execution as 'beforeTest' step to make sure same data is re-usable everytime .

As it is inserted as pre-step on the test suite level so it is always executed and further steps are only executed if pre-condition is met (on data deleted successfully).