Solvedtestcafe Add the capability to disable page reloading between tests

Based on the #1509 question. It's actual for the SPA apps.

45 Answers

✔️Accepted Answer

I think this would be hugely beneficial for single page applications, but I also think it should be an explicit opt-in so that a user is aware that they are not starting with a blank slate for each test and that people testing regular websites are not affected.

One of the things that is more difficult in a SPA is managing the client side state. Every time you refresh the page, the app bootstraps so you're in a pristine state, but some of the more difficult to track bugs in a SPA arise after editing an item, navigating and expecting an unrelated component to be updated.

A typical scenario for me would be:

  1. Navigate to an edit page, test the inputs - cascading dropdowns, field enabled/disabled or hidden based on user selection etc.
  2. Click the in-app save button - this saves the item
  3. Navigate back to a grid page - the updated (or newly added) item should appear in the grid.
  4. Depending on the item saved it could update other parts of the UI - saving a user for example could update a status bar containing the current user name.

A test like this could be achieved by putting all logic within a test(), but it would be nice to separate these different test responsibilities into different tests(), but at the moment if I put them in different tests(), the page reloads and I'm not testing that the client side behaviour is correct.

Currently a test like this would be written

fixture("test save item saves a updates grid');

test("check inputs, save, navigate, check grid" async t => {
  //test cascading dropdowns
  //check boxes
  // assert items are enabled/disabled etc
  // do a save
  // assert no validation errors
  // navigate to grid page
  // assert updated item exists in grid
});

IMO, a nicer way to write these would be each test has a single responsibility

fixture("test save item saves a updates grid', { noReloadBetweenTests: true });

test("check inputs" async t => {
  //test cascading dropdowns
  //check boxes
  // assert items are enabled/disabled etc
});
// No page refresh please!!

test("save without validation errors" async t => {
  // do a save
  // assert no validation errors
});
// No page refresh please!!

test("item exists in grid" async t => {
  // navigate to grid page
  // assert updated item exists in grid
});

The fact that it would improve the performance of running the tests in the fixture would be a bonus (for me) rather than the goal.

As mentioned by @iexplore in #1509, enabling this via a 'noReloadBetweenTests' option or similar on the fixture would be a great solution to this.

Other Answers:

Before:
image

After using @AndreyBelym no-reload-demo-1

After:
image

~400% faster

+1 for adding noReloadBeetweenTests option.
Same as in a couple of comments above - I would rather utilize test cafe's ability to define more granular tests, but due to my system under test being a SPA - I can't achieve this. I end up with much larger tests that test multiple things at once.

I like so much about test cafe but I think this will be a deal breaker for a lot of people testing SPA's. I've followed this thread for about a year now and IMO it's much more of a philosophical difference rather than any technical limitation. It's up the owners of this project to decide the direction they want to pursue and I respect that. But closing this issue flies in the face of how developers of SPA's work and also how they behave at runtime. It strikes me as purism over practicality and I say this with a lot of respect for the testcafe development team as, aside from this, it truly is an excellent tool. IMO, testing SPA's will not be a 1st class citizen in testcafe unless this scenario is addressed

I understand the "current" implementation is for internal use only, but I just want to report that even the current undocumented implementation does not work when used together with the Roles feature. Using useRole() will always trigger a refresh, even if the start/end page are the same URL.

More Issues: