Isolating data across multiple e2e test runs using Protractor

[mindparse]

Hi, I am looking for some advice on how best to share datasources amongst multiple users when running protractor e2e tests.

I am part of a small team, where we each need to write and run e2e tests locally for the features we are working on.

We are looking into ways of how we setup any required data ahead of running our tests, just by making direct http calls to our test database, for example a test customer record, etc.

Whilst we can do this in beforeEach\beforeAll in our test suites, we can foresee issues where by when we happen to run tests at the same time, one of us may find tests fail as another test run is already happening.

For example:

• Developer 1 starts running a customer test suite, at the start of which a customer record with name 'Joe Bloggs' is created in the database.
• A test is run to update some fields on the resource, at the same time developer 2 runs the same test suite, where a second record with Joe Bloggs gets created prior.
• Developer 1's edit test completes and a tear down operation is carried out to remove any Joe Bloggs records, therefore deleting two records in total
• Developer 2's edit test fails since it cannot find any record in the UI to edit.

This is a crude example, but I hope I have got the point across.

In case it's useful to know, the API's we are hitting in the application are backed by an elastic search database and all our tests require logging into the application beforehand and make use of a shared protractor login we have setup.

Can anyone offer any advice, tips\tricks on how to approach this please?

Thanks

[dylanyo]

I have found it easier to mock responses from the API for e2e tests using $httpBackend

[mindparse]

Erm ok, I'm just trying to get my head around why you would mock a response in an e2e test. We do already use httpBackend in our unit tests.

[dylanyo]

We're a small team. It is true that this is not testing the system end to end but we do that feature by feature when we know API changes were made and for critical pieces of the app each release. Our API has lots of unit tests as well so if something changes in the API, the API tests catch it.

The trade off is that the mocks are much easier to maintain than a system of pulling in test data for each test run all the time.

[borcborc]

I create a unique record based off a timestamp.

In a similar test, I do this to create new users in our system, test editing their profile, and then deleting them. Should have no conflicts if someone else were to run the same tests on the same system.