0

I require to login certain users among the test users created in test classes.

Each user is created as follows:

User user = new User(Alias='test', Email='test@none.com');
insert user;

I create multiple such sample users.

My business logic class checks for logged in users via:

List<AuthSession> sessions = [Select UserId From AuthSession];

UserId in this list tells me which users are logged in.

How can I login my user programmatically in my test case?

Edit:
I run a scheduled Apex class which assigns a particular lead from a Queue to one among list of users. Scheduler runs as Admin. It needs to check which among UserA, UserB or UserC is Logged in.

To make this check I use AuthSession to determine which users are logged in. UserInfo contains information about Admin which is irrelevant. Under this light is there alternative to AuthSession?

In test case, I create mock users and need to simulate some among them are logged in. So that I can test if my business logic works well to skip assignment for 'Not logged in users'.

9

The System.runAs() method allows you to establish a new user session in unit test context. To adapt the example in the linked documentation,

@isTest
public static void testRunAs() {
    String uniqueUserName = 'standarduser' + DateTime.now().getTime() + '@testorg.com';
    Profile p = [SELECT Id FROM Profile WHERE Name='Standard User'];
    User u = new User(
        Alias = 'standt', 
        Email='standarduser@testorg.com',
        EmailEncodingKey='UTF-8', 
        LastName='Testing', 
        LanguageLocaleKey='en_US',
        LocaleSidKey='en_US', 
        ProfileId = p.Id,
        TimeZoneSidKey='America/Los_Angeles',
        UserName=uniqueUserName
    );

    System.runAs(u) {
        System.assertEquals(u.Id, UserInfo.getUserId(), 'running as new user');
    }
}

As far as I can tell, however, it doesn't work with the AuthSession sObject. Doing

    System.debug('AuthSession.UsersId = ' + [SELECT UsersId FROM AuthSession]);

inside a System.runAs() block returns no rows.

That leaves a couple of approaches for you:

  1. Use UserInfo.getUserId() instead of querying AuthSession. (I'm not sure what reasons led you to utilize the sObject, so I don't know if this is workable or not).
  2. Use a dependency-injection approach to mock the query. This might require extensive rework of your code, and we can't see enough in your question to be sure.

Edit- Multiple user scenario

You are not going to be able to have multiple users logged in during a unit test. Instead, you will have to take approach (2) above and factor your query against AuthSession into a dependent class. You'll then need to utilize dependency injection in the test context to provide a mock implementation so that you can directly control the data returned to the class being tested.

  • This does not help me. I do no need to run anything as other user. I simply need to see how many users are logged in. I will make additions to question as well – devilpreet Jan 17 at 16:09
  • I would try Injection mentioned in approach 2. Overall, does it mean I cannot programmatically log in a particular user, which is not my current user? – devilpreet Jan 17 at 16:26
  • You can programmatically change the user context to exactly one user in the way that my original answer described, using System.runAs(). If you do so, you cannot access AuthSession. You cannot otherwise log in a user in a test context, or more than one user at at time. – David Reed Jan 17 at 16:27
3

In order to have a test execute statements as if these were performed by a specific user, use the System.runAs method. This delimits a block of code and executes that code with the specified user as the contextual user for execution.

I'm not convinced you should be checking the AuthSession table. Could you not get the current user from UserInfo instead?

This is covered nicely in the apex documentation.

  • Information added to my question accordingly. UserInfo does not help. – devilpreet Jan 17 at 16:17

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.