# Understanding MOSIP Functional Test Cases and Automation Framework **URL:** \ **Category:** Support\ **Created:** [September 15, 2026, 3:09pm UTC](https://community.mosip.io/t/understanding-mosip-functional-test-cases-and-automation-framework/2895 "2026-09-15T15:09:57Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![RIKHITH\_NAIK1](https://dub1.discourse-cdn.com/flex017/user_avatar/community.mosip.io/rikhith_naik1/32/2112_2.png) [@RIKHITH\_NAIK1](https://community.mosip.io/u/RIKHITH_NAIK1)\ **Post date:** [September 15, 2026, 3:09pm UTC](https://community.mosip.io/t/understanding-mosip-functional-test-cases-and-automation-framework/2895/1 "2026-09-15T15:09:57Z")
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 ! ---
**Author:** ![mrudula](https://avatars.discourse-cdn.com/v4/letter/m/a587f6/32.png) [@mrudula](https://community.mosip.io/u/mrudula)\ **Post date:** [September 17, 2026, 5:22am UTC](https://community.mosip.io/t/understanding-mosip-functional-test-cases-and-automation-framework/2895/2 "2026-09-17T05:22:52Z")
Hi **[RIKHITH\_NAIK1](https://community.mosip.io/u/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 ---
**Author:** ![RIKHITH\_NAIK1](https://dub1.discourse-cdn.com/flex017/user_avatar/community.mosip.io/rikhith_naik1/32/2112_2.png) [@RIKHITH\_NAIK1](https://community.mosip.io/u/RIKHITH_NAIK1)\ **Post date:** [September 17, 2026, 2:09pm UTC](https://community.mosip.io/t/understanding-mosip-functional-test-cases-and-automation-framework/2895/3 "2026-09-17T14:09:49Z")
Thank you for the response **mrudula**. Looking forward for the **information .** ---
**Author:** ![mrudula](https://avatars.discourse-cdn.com/v4/letter/m/a587f6/32.png) [@mrudula](https://community.mosip.io/u/mrudula)\ **Post date:** [September 22, 2026, 4:57am UTC](https://community.mosip.io/t/understanding-mosip-functional-test-cases-and-automation-framework/2895/4 "2026-09-22T04:57:44Z")
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 →](https://github.com/mosip/test-management/tree/master/Master_Testcases)`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. -Denv.endpoint= -Denv.testLevel=smokeAndRegression -jar apitest-idrepo--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](https://github.com/mosip/mosip-automation-tests/blob/master/docs/DSL_SCENARIO_AUTHORING_GUIDE.md) 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](http://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. ---
**Author:** ![system](https://europe1.discourse-cdn.com/flex017/uploads/mosip1/original/1X/f60a343830fe848c9a68e2d1cc654d0cb7fbbaf2.svg) [@system](https://community.mosip.io/u/system)\ **Post date:** [October 2, 2026, 4:57am UTC](https://community.mosip.io/t/understanding-mosip-functional-test-cases-and-automation-framework/2895/5 "2026-10-02T04:57:56Z")
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.