I've been evaluating TestCafe for an app that requires user authentication. The documentation isn't very clear and I've had trouble getting a straight answer on how we should be using useRole.
Our application requires user authentication, right now we only test a single user so we have no need to switch user sessions.
I've defined a Role and it authenticates correctly. But I've noticed the following:
I need to call useRole first in every test in order to use the authenticated session
Every time useRole is called (first in every test) TestCafe navigates the browser back to the original login URL (or whatever preserveUrl saves post-login)
Are either of these statements wrong? I can't imagine how this works in a real environment, that's an insane amount of redirects.
Item 2 seems correct, a devexpress github contributor replied "Currently, TestCafe can't use a Role without reloading or triggering page navigation" so if I have to call useRole in every test that's literally doubling the HTTP navigation load.
The purpose of useRole is to authenticate to the app only once (per user): this means you will see the login page in the first test, and all other tests will start directly on the App page with the user being already authenticated.
The problem is that every test runs in a sandbox. The sandbox is per test and not per fixture. This means that when a test starts to execute, it starts in a brand new sandbox with no cookies and no local storage.
The only way to re-apply cookies and local storage is to call useRole. This is why useRole must be called at the beginning of each test.
useRole is a huge time saver. When I started to work with TestCafe (more than one year ago) useRole did not exist and each test would start by feeding the login page.
useRole is even more useful when you need to switch, inside a test, between different users.
And then to finish, yes, useRole reloads the App page because each test starts in a sandbox with no page history.
What you are looking for is a feature that does not exist: do not reload page between test. If you do not want to reload the page each time, do all you tests in a single test method.
Related
I am doing load tests to a apply option of career fair section. But I have only one user's login informations and I want to do apply tests more than one time with same user. For example when I create 10 users with Thread Group, the http request for apply is going to be fall 9 times. I think that's why we use only one user and the apply button is going to be applied button and not clickable. How can I do this test?
There is one golden rule: 1 virtual user == 1 real user with all its stuff like credentials, permissions, business actions, cookies, cache, etc. See How to make JMeter behave more like a real browser article for more details.
So ideally you need to have as many credentials as threads (virtual users) you set in JMeter's Thread Group
Test need to be repeatable, to wit leave the system in unmodified state so you could re-run the test once again. If the application process is irreversible you need to either cancel the application somewhere in the tearDown Thread Group or modify the database using JDBC Test Elements to restore the system state
If your system doesn't allow multiple logins from one user I don't think you will be able to conduct your test with a single user for multiple sessions.
Let's say I'm testing a web service and I have a couple of scenarios requires user to be authenticated:
Scenario #1: Customer sign-up
Scenario #2: Customer sign-in
Scenario #3: Customer change name
Scenario #4: Customer update image
Should all the tests go through all login steps like:
1) Go to register page
2) Enter new user information
3) Activate account
4) Go to login page
5) Enter login and password
6) Press the Login button
7) Check if I authenticated as a customer
Or I can just test it once and implement endpoint which quickly creates a user and log it in.
So if I have that kind of endpoint that means I can skip retesting the same things all the time and just have short scenarios #3 and #4 implementation. But in this case, I have a less natural environment.
Please tell me about the best practices that you use in real projects.
Few best practices:
use the testing pyramid integration > ui (tests are much slower on UI, automate in the UI only the necessary things to have main flows covered)
for the UI use fast methods for the setup (so yes, web services, test login only once)
if possible keep some test data trough the builds (for example to make sure a new build that might change data structure does not affect basic functionality, e.g. login)
tests should be atomic (not depend on each other)
do some cleanup from time to time to remove duplicate test code and to improve the framework(speed, stability)
You shouldn't copy and paste the "log in" scenario to all of the other scenarios, but having an account and being logged in are prerequisites for the other use cases. From a behavior driven development perspective this will translate to one or more Given steps that simulate or actually perform those steps:
Scenario: Customer change name
# Calls web service or database to create new user
Given "Bob" is a registered user
# Calls web service or database to make account active
And "Bob" has an active account
# Opens browser, navigates to login page, fills out login form and submits it
And the user is logged in as "Bob"
# Steps specific to changing name and asserting it has changed
When the user changes their name to "Samuel"
Then the user's name is "Samuel"
I am using TestCafe for my E2E testing.
Scenario: I am running a test use test runs. For example, first test run executes tests in firefox browser, and next run in chrome (this is just example, I have cases where I need to run e2e tests in different stages as well). I have used a role. When one test run completes, and it is running another test run, still the role cookie persists, and it acts as the user is logged in.
Expected behavior: Roles should be re-initialized for each run.
Is there some way I can clean the cookie, or un-initialize the roles?
The Role functionality was created to save time by saving the state of cookies and (local|session)Storage and applying them on the second and subsequent role calls. If you want to perform login actions on each test, just transfer the actions from your role to a separate function and call this function instead of the role. If your goal is different, please add the example that illustrates the current behavior and describe what task you would like to accomplish.
User Roles documentation.
I am testing a platform using testcafe for end to end tests. I have a case for testing login but I have other cases that require login.
I am not sure what is the best option I should run login on every test case setup or should run first a script login and then run all tests? I have tried both and they seem good options.
Having to log in for each and every test is time-consuming and inefficient. I would recommend having a single login for the tests if;
There is no dependency between the logged in user and the test that is running.
The actual result you are looking for can be achieved by just a single login
Furthermore, I would use 2-3 users for tests just to be cover multiple users login into the system.
TestCafe has powerful mechanism of Roles for testing login/logout functionality.
You can create Role for each user account which you would like to test and switch between them in tests. To switch to an unregistered user, you can use Role.anonymous().
The main profit of using Roles is that logging steps are executed only one time during first using of Role and next time TestCafe just reloads the page and restores required credentials.
It depends what you are testing:
If you are testing the authentication then they should login each time.
If you are testing something else then I would place this in the Arrange part of the code following the Arrange Act Assert pattern as it's not relevant to the other tests and as part of the test setup (Arrange) it should navigate back to the home page.
Ideally you isolate the authentication from other tests for performance, however if your session has some state that it has carried over from the last test you should clean this up so other tests are not effected by it.
A comment in the Git issue suggests that you can use preserveUrl to keep your session.
I want to write up a scenario that looks something like:
Given I am logged in
And I am on my profile page
Then I see my name
For the "Given I am logged in" - do I need to write something like:
When I go to the log in page
And I fill in "user_username" with "test"
And I fill in "user_password" with "invalid password"
And I press "Sign in"
Question is: does the test have to go through the login scenario every time I test a logged in user functionality?
EDIT:
Note that I am using the Devise gem. I am not sure how to log in the user directly since the user session, cookies, etc have to be set
I would write a step definition to handle the login instead of a scenario.
This step definition can then put the cookies in the cookie jar for subsequent use.
If you store the cookiejars in a hashmap keyed on the test users then the method can be smart enough to only log in when needen and reuse a session if one is still available. This can save a lot of time in the tests at the expense of not having completely independent tests, since now they're coupled through the session data on the server. The session can always be cleared by logging out before logging in again.