Feature
Currently, only cookies (I think?) get saved when Role snapshots are taken. In recent releases of firebase, user state information is stored in IndexDB. As a result, switching roles does not changed the authenticated user.
Similarly, switching to an anonymous Role stays logged in as the indexDB is not cleared.
Creating a role and switching to a role changes the logged in user.
These issues refer to resetting, but need to apply to taking snapshots as well:
I think exposing Role with a callback to enable devs to decide what to save and what not to the browser is a much better option. Or expose the Testcontroller in before hook so we Devs can do all of it ourselves is even better.
Is this issue something that is likely to be fixed? It appears with this limitation that it's impossible to use Testcafe Roles with Firebase, Google's preferred user management toolset...
Hello, yes we have this feature planned, continue to follow this thread to stay tuned
@AlexanderMoiseev Awesome! Thanks. If you want a beta tester I'd be happy to help.
Is there any suggestion for how to work around the incompatibility of Testcafe Roles & Firebase? I am on an ancient version of Firebase and need to upgrade, but my test suite is built with Roles as a key building block. Re-writing all my tests would be very unpleasant....thanks for any suggestions.
Hello, @viking2917,
IndexedDB proxying is a pretty big and complex feature. Right now team is busy with implementing multi-window API.
As a suggestion, you could try saving and restoring the IndexedDB state manually. In Role, use ClientFunction that fetches and returns serialized IndexedDB data and save the serialized state in a global variable in your test. Then use another ClientFunction before calling "t.useRole" to restore the saved IndexedDB state from a global variable.
Another possible workaround is replacing your Role with the following FallbackRole, that doesn't try to save and restore the page state but always executes authentication steps:
import { Role } from 'testcafe';
function FallbackRole (url, body) {
const role = Role(url, body);
const originPhase = role.phase;
Object.defineProperty(role, 'phase', {
get: () => originPhase,
set: () => {}
});
return role;
}
fixture `1`;
const role = FallbackRole('example.com', () => console.log(123));
test('1', t => t.useRole(role));
test('2', t => t.useRole(role));
@wentwrong Thanks for these suggestions. I'm relatively unfamiliar with IndexedDb, so I think I may try a variant of option 2. It may be that my tests don't really rely too much on app state other than authentication so just building my own FallbackRole to replace existing useRole (re)authentication, and tweaking the tests, may not be too bad.
I appreciate the suggestions!
Most helpful comment
Hello, yes we have this feature planned, continue to follow this thread to stay tuned