Parallel testing conundrum.

[Gheeno San Pascual III]

Not sure if anyone has experienced this. 

Has anyone experienced an issue where you get a "collision" on data creation ( I am using REST ASSURED to create new data ) when you run on Parallel?

The issue I am facing is, whenever I make a GET call to retrieve the next available ID for a user - if the test runs in parallel, all scenarios get the same ID. ( which is expected since when you do a GET, you only get what's available. ) 

What did you do to solve this issue? Or what would you advise me to do? 

Here's the feature file sample I am playing around with.

@sample
Feature: Create a bunch of users
  New users can be made using API.

  @common
  Scenario: New user is created.
    Given A Marketing user from Store1 is created 

## output here is userId = 1

  @common
  Scenario: New user is created.
    Given A Cashier user from Store2 is created

## output here will also be 1

  @common
  Scenario: Fgl : new user is created.
    Given A Store System Support user from Store1 is created

## so is this 

[Andrew Premdas]

Why do you think this is a collision, surely you would expect each scenario to create a user with id 1, because the db is reset between scenarios. If you are running in parallel, you should be running a separate db instance for each parallel instance. Or are you trying to use a single db instance?

Secondly why does it matter. Are you using the expected id in some later steps (a bad idea)

--
Posting rules: https://cucumber.io/support/posting-rules
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cukes/807e4dc8-0042-4e24-8f10-e9b46299ee76%40googlegroups.com.

--

------------------------

Andrew Premdas

blog.andrew.premdas.org

[George Dinwiddie]

On 2/17/20 4:27 AM, Andrew Premdas wrote:
> Why do you think this is a collision, surely you would expect each
> scenario to create a user with id 1, because the db is reset between
> scenarios. If you are running in parallel, you should be running a
> separate db instance for each parallel instance. Or are you trying to
> use a single db instance?

That's a good point, Andrew, if the ID is being set in the code. I'm
accustomed to the ID being created by the database using a trigger and a
sequence counter, or some similar identity value generator. In that
case, using a single DB instance would be fine, as the database would
take care of creating unique IDs.

>
> Secondly why does it matter. Are you using the expected id in some later
> steps (a bad idea)

Far beyond testing, database IDs are generally surrogate keys, created
for the convenience of database technology, and divorced from the
business domain. They should, at most, be used as handles to indicate a
record. Proliferating key references in either production code or test
code takes the focus off of the business domain and onto the database
implementation.

- George

>
> On Thu, 13 Feb 2020 at 22:23, Gheeno San Pascual III
> <gino.sa...@gmail.com <mailto:gino.sa...@gmail.com>> wrote:
>
> Not sure if anyone has experienced this.
>
> Has anyone experienced an issue where you get a "collision" on data
> creation ( I am using REST ASSURED to create new data ) when you run
> on Parallel?
>
> The issue I am facing is, whenever I make a GET call to retrieve the
> next available ID for a user - if the test runs in parallel, all
> scenarios get the same ID. ( which is expected since when you do a
> GET, you only get what's available. )
>
> What did you do to solve this issue? Or what would you advise me to do?
>
> Here's the feature file sample I am playing around with.
>
> @sample
> Feature: Create a bunch of users
> New users can be made using API.
>
> @common
> Scenario: New user is created.

> Given AMarketing user fromStore1 is created

>
> ## output here is userId = 1
>
>
> @common
> Scenario: New user is created.

> Given ACashier user fromStore2 is created

>
> ## output here will also be 1
>
>
> @common
> Scenario: Fgl : new user is created.

> Given AStore System Support user fromStore1 is created

>
> ## so is this
>
> --

> ------------------------
> Andrew Premdas
> blog.andrew.premdas.org <http://blog.andrew.premdas.org>
>

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach
----------------------------------------------------------------------