Two step types connect a Test Case to an Authenticated Profile. Inject Profile loads a saved session so the Test Run starts signed in, and Capture Profile saves the current session as a Profile part-way through a run. Most Test Cases only need Inject Profile, at the very top, in place of the sign-in steps you would otherwise write.
Both steps find a Profile by its name, which is why Profile names matter and why renaming one breaks the steps that point at it.
Inject a saved session
Open the Test Case and add a step.
Choose Inject Profile, and put it first, before anything that needs a signed-in user.
Pick a Saved profile from the list, or type a name.
Save the step.
The Test Run now begins with your application already signed in, and your remaining steps can go straight to the screen under test.
If no saved Profile matches the name, the editor warns you up front: "No saved profile is named X. The step fails unless an earlier step captures it." That is a warning rather than an error, because a Capture Profile step earlier in the same test is a legitimate way to create it.
Reserve a profile with Exclusive
Inject Profile has an Exclusive option. It reserves the Profile for this Test Run, and other runs that inject the same Profile wait until this one finishes, then continue. A run that waits more than 15 minutes fails.
Use it when the Test Case changes state that belongs to the signed-in user, such as editing that user's settings or consuming a one-time item. Two Test Runs doing that at once on the same account interfere with each other, and the failures look random.
Leave it off for Test Cases that only read. Reserving a Profile that many Test Cases share turns parallel runs into a queue, which is a common cause of a suite that suddenly takes far longer.
Save a session during a Test Run
Capture Profile stores the current browser session under a name you choose. Put it after steps that sign in.
Use it when the sign-in must happen inside the Test Case, for example when the account is created earlier in the same Test Run, and you want later Test Cases to reuse the result.
Build the name at run time
Both steps accept a Variable in the Profile name, so one Test Case can reach a different Profile per Environment or per data row.
Write the name with a Variable in it, for example acme-[ENVIRONMENT_NAME], and Thunders resolves it when the step runs. A Profile name cannot contain the | character.
Frequently asked questions
Where should the Inject Profile step go?
First, before any step that assumes a signed-in user. Injecting after you have already navigated means the earlier steps ran signed out.
When should I turn on Exclusive?
When the Test Case writes state belonging to the signed-in user, so two Test Runs cannot collide on the same account. Leave it off for read-only Test Cases, because it serializes every run that injects that Profile and one waiting over 15 minutes fails.
How do I keep Inject Profile steps working over time?
Keep the Profile name stable, since steps resolve a Profile by name, and watch its status in the Authenticated Profiles list. Active means it is good to go; Expiring soon is your cue to record it again before anything fails.
Can I use the same Profile in several Test Cases at once?
Yes, as long as Exclusive is off. With Exclusive on, the Test Runs queue behind each other.
What replaces my login steps?
A single Inject Profile step at the top of the Test Case. That is the whole point: it takes out the part of a test most likely to break on a multi-factor prompt or a redirect, and it makes every run start faster.
Can I use a Variable for the Profile name?
Yes. Both steps accept one, so acme-[ENVIRONMENT_NAME] resolves at run time. The name cannot contain |.