Understanding MOSIP Functional Test Cases and Automation Framework

Support
1

Hi MOSIP team ,
We are reviewing the MOSIP Functional Test report and would like to understand the test automation framework in more detail .
Could you help us with :
1)Test cases :

  • Where can we find the actual functional test cases , including their descriptions , steps , expected results and test data ?
  • Is there a mapping between these functional test cases and the automated test cases ?
    2)Automation Framework
  • Which repository/framework should we use for functional/API/DSL automation ?
  • How can we setup, execute and run a specific test case or scenario ?
    3)Creating our own tests :
  • How can we create and automate our own tests cases using the existing framework ?
    Our goal is to understand the framework and start creating and maintaining our own automated test cases .

Thank you for your guidance and support !

2

Hi RIKHITH_NAIK1

Thank you for your query. We will review the details and provide the required information as soon as possible.

Regards,
Mrudula
on behalf of Team MOSIP

3

Thank you for the response mrudula . Looking forward for the information .

4

Thanks for the detailed questions — the earlier docs are a bit dated since we recently restructured the test repos, so here’s the current picture.

  1. Test cases
  • Master test case definitions (description, steps, expected result, test data) live in the test-management repo → Master_Testcases. This is the source of truth for the functional test case catalog.
  • Mapping to automated tests: each automated test case’s name/ID in the module testrigs (e.g. AddIdentity_withValidParameters_smoke_Pos) is meant to trace back to a Master_Testcases entry. There isn’t a single cross-reference spreadsheet published today — the naming convention plus the YAML test-data files in each module’s api-test/src/main/resources folder are currently how you correlate the two. Happy to flag this as a gap if a formal mapping doc would help.
  1. Automation framework
    The repo layout changed recently — all module-level testrigs used to live together in mosip-functional-tests; they’ve now moved into each module’s own repo, and mosip-functional-tests only retains the shared apitest-commons library (published to Maven Central, consumed as a dependency by every module’s testrig).
  • API test framework (per module): Each service module now ships its own api-test folder — for example, id-repository/api-test. It’s built on Java + REST-Assured + TestNG, uses Smoke and Regression test categories, and covers only the module’s external API endpoints. All modules follow the same pattern (same Maven structure, same MosipTestRunner entry point, same JAR-based or IDE-based execution), so once you’re comfortable with one module’s api-test, the others should feel familiar.
    • Setup: clone the module repo → update the module’s properties file (e.g. Idrepo.properties) with client secrets/credentials → mvn clean install -Dgpg.skip=true -Dmaven.gitcommitid.skip=true.
    • Run via JAR: java -jar -Dmodules=idrepo -Denv.user=api-internal.<env_name> -Denv.endpoint=<base_env> -Denv.testLevel=smokeAndRegression -jar apitest-idrepo-<version>-jar-with-dependencies.jar
    • Or import as a Maven project in Eclipse/IntelliJ and run MosipTestRunner directly with the same VM args (-Dmodules, -Denv.user, -Denv.endpoint, -Denv.testLevel).
    • Results land in api-test/testng-report.
  • UI test framework (per module): Follows the same pattern, e.g. admin-ui/uitest-admin — Cucumber + Selenium (BrowserStack-integrated) driven off the module’s UI repo.
  • DSL / end-to-end automation: Lives in mosip-automation-tests, which orchestrates full registration / pre-registration+registration / authentication flows on top of apitest-commons. It has two main pieces:
    • IVV Orchestrator — the DSL test runner (io.mosip.testrig.dslrig.ivv.orchestrator.TestRunner), with scenarios defined in Gherkin (scenarios.feature) and a scenariosToExecute property to run one scenario or the whole suite.
    • Packet Creator / Test Data Provider — generates and uploads the test packets the DSL scenarios consume.
    • There’s a dedicated DSL Scenario Authoring Guide for writing new scenarios.
  1. Creating and maintaining your own tests
  • For API tests, new test cases are almost entirely data-driven — you add entries to the module’s YAML resource files (e.g. AddIdentity.yml, UpdateIdentity.yml for idrepo) rather than writing new Java classes for each case. The Java classes (testscripts/*.java, utils/*.java) handle templating (via Handlebars against the live schema), token substitution, and edge-case dispatch logic; you’d only touch Java if you’re adding a genuinely new mutation pattern.
  • Each module’s api-test folder that has a CLAUDE.md/agent guide (like id-repository/api-test/CLAUDE.md) documents the module-specific internals — key files, schema-driven request generation, test chains, and known pitfalls. It’s written for AI coding agents but is equally useful as a deep-dive reference for a human building new test cases on that module — worth reading before you start authoring.
  • For DSL/E2E, new scenarios are added in Gherkin following the authoring guide above, then wired into scenarios.feature.
  • For UI, follow the same Cucumber/Selenium/Page-Object pattern already in the module’s uitest-* project.

Notes / caveats

  • The older docs.mosip.io pages on test-rig automation (API/DSL/UI) predate the repo split above and describe the old “everything lives in mosip-functional-tests” layout — treat those as historical context for now; we’ll get them updated.
  • If you tell us which module(s) you’re targeting first, we can point you at that specific api-test/uitest-* repo and walk through a first test case together.

Ping us here with any specific module or step you get stuck on — happy to go deeper.