Testing Multi‑Project Single Sign‑On with Groovy Scripts for Simultaneous Web and Pad Login

The author revisits a previous single sign‑on performance testing solution and introduces a new requirement: the same account must remain logged in simultaneously on a web client and a pad client without mutual kicking, and changing the password on either side must not invalidate the other session.

Functional testing of this requirement normally involves calling three to four APIs, which is cumbersome with tools like postman or JMeter because token handling and the existing SSO integration prevent direct token reuse.

To address this, the author shares two Groovy test scripts that use a custom Java test framework (based on TestNG and RestAssured) to perform the necessary API calls.

Requirement 1 script:

package com.okayqa.teacherpad

import com.fun.frame.SourceCode
import com.okayqa.appmiddle.function.UserCenter
import com.okayqa.teacherpad.function.UserInfo

class TEA_PAD22 extends SourceCode {
    public static void main(String[] args) {
        def base1 = new com.okayqa.teacherpad.base.OkayBase(2)
        new UserInfo(base1).getUserInfo()
        def base2 = new com.okayqa.teacherweb.base.OkayBase(2)
        new UserCenter(base2).getGrades()
        allOver()
    }
}

Requirement 2 script (adds password modification):

package com.okayqa.teacherpad

import com.fun.frame.SourceCode
import com.okayqa.appmiddle.function.UserCenter
import com.okayqa.teacherpad.function.UserInfo

class TEA_PAD22 extends SourceCode {
    public static void main(String[] args) {
        def base1 = new com.okayqa.teacherpad.base.OkayBase(2)
        def base2 = new com.okayqa.teacherweb.base.OkayBase(2)
        new UserInfo(base1).modifyPassword(base1.getUname())
        new UserCenter(base2).getGrades()
        allOver()
    }
}

The scripts can be executed directly on a server using the command groovy test.groovy or via the Java test framework described in a linked article.

Since the scripts lack explicit assertions or reporting, the author suggests validating success by checking the HTTP status code, parsing the JSON response, and verifying fields such as response code, message, and business‑specific data (e.g., teacher name and subject).

Additional helper methods shown include getUserInfo and modifyPwd, which handle API calls, token updates, and logging.

For alerting, the author references an implementation of the AlertOver push API using Java HttpClient, noting that push levels can be configured in the console.

While these scripts are not full‑featured automated test cases, they provide a quick way to run the required checks on a server; a more comprehensive automation setup would need test management, reporting, and execution orchestration.

Disclaimer: Original content first published on the "FunTester" public account; reproduction without permission (except Tencent Cloud) is prohibited.