Munit: Parameterized Test Suite

This article explains the usage of parameterized test suites using Munit tests to validate every request field present in the request payload.

👁 Ankur Bhuyan user avatar

Ankur Bhuyan

Feb. 07, 24 · Code Snippet

Likes (40)

Comment

Save

3.9K Views

Join the DZone community and get the full member experience.

Join For Free

The purpose of this use case is to explain how to define different RAML data types, define the business-related status code for request payload validation, define the single unit test case for multiple field validation with dynamic request payload, and how to use the parameterized test suite.

With a parameterized test suite, we can write a reusable unit test case. It can help to write and test multiple scenarios based on different inputs with a single test case. This can be more useful when we are writing a test case to validate the request and response payload.

RAML Data Types Definition

Define different types of data types for a request payload.

In the below example, I covered integer, string, pattern, enum, array, object, datetime, datetime-only, and time-only.

YAML

#%RAML 1.0 DataType

type: object
properties:
 employeeId: 
 type: integer
 required: true
 minimum: 8
 firstName: 
 type: string
 required: true
 minLength: 1
 maxLength: 10
 pattern: ^[A-Za-z]*
 lastName: 
 type: string
 required: true
 minLength: 1
 maxLength: 10
 pattern: ^[A-Za-z]*
 email:
 pattern: ^.+@.+\..+$
 gender:
 enum: [male, female]
 default: male
 required: true
 dateOfBirh:
 type: date-only
 required: true 
 addresses:
 type: array
 minItems: 1
 items:
 type: object
 properties:
 isPermanent:
 type: boolean
 required: true
 street:
 type: string
 required: true
 minLength: 5
 maxLength: 50
 pattern: ^[A-Za-z ]*
 district:
 type: string
 required: true
 minLength: 3
 maxLength: 20
 pattern: ^[A-Za-z]*
 state:
 type: string
 required: true
 minLength: 5
 maxLength: 15
 pattern: ^[A-Za-z]*
 pinNumber:
 type: integer
 required: true
 minimum: 6
 province:
 type: string
 required: true
 minLength: 1
 maxLength: 10
 pattern: ^[A-Za-z]*
 phoneNumber:
 type: string
 required: true
 minLength: 1
 maxLength: 13
 pattern: ^\s*|^(0|91)?[6-9][0-9]{9}$
 created:
 type: datetime
 format: rfc3339
 required: true
 createdDateTime:
 type: datetime-only
 required: true
 createdTime:
 type: time-only
    required: true

Sample Request Payload

Based on the RAML definition, prepare a valid request payload.

JSON

{
 "employeeId": 12345678,
 "firstName": "Ankur",
 "lastName": "Bhuyan",
 "email": "[email protected]",
 "gender": "male",
 "dateOfBirh": "2000-04-01",
 "addresses": [
 {
 "isPermanent": true,
 "street": "teachers colony",
 "district": "Sunitpur",
 "state": "Assam",
 "pinNumber": 784507,
 "province": "Tezpur",
 "phoneNumber": "+919590951234"
 }
 ],
 "created": "2016-02-28T12:30:00.090Z",
 "createdDateTime": "2016-02-28T12:30:00",
 "createdTime": "12:30:00"
}

Configure Parameterized Test Suite for Valid Scenarios

This is a valid test case scenario for which the parameterized inputs are defined. Based on the parameterization "name" defined, the test result name will be prepared (once the test case is executed). We have defined only one property with which the input payload for the test case will be prepared, which will vary based on the test scenario we will cover.

XML

<munit:config name="apikit-valid-test-suite.xml" >
	<munit:parameterizations >
		<munit:parameterization name="001" >
			<munit:parameters >
				<munit:parameter propertyName="caseNumber" value="001" />
			</munit:parameters>
		</munit:parameterization>
	</munit:parameterizations>
</munit:config>

Configure Parameterized Test Suite for Invalid Scenarios

This is an invalid test case scenario for which the parameterized inputs are defined.

We can add as many numbers of the parameter (like caseNumber, expectedType, expectedCode) based on the use case. This is an example to show how we can define multiple parameters for a single test case.

XML

<munit:config name="apikit-invalid-test-suite.xml">
	<munit:parameterizations >
		<munit:parameterization name="001" >
			<munit:parameters >
				<munit:parameter propertyName="caseNumber" value="001" />
				<munit:parameter propertyName="expectedType" value="REQUIRED_KEY" />
				<munit:parameter propertyName="expectedCode" value="ANK000001" />
			</munit:parameters>
		</munit:parameterization>
		<munit:parameterization name="002" >
			<munit:parameters >
				<munit:parameter propertyName="caseNumber" value="002" />
				<munit:parameter propertyName="expectedType" value="TYPE" />
				<munit:parameter propertyName="expectedCode" value="ANK000002" />
			</munit:parameters>
		</munit:parameterization>
 <!-- define all posible test parameters -->
	</munit:parameterizations>
</munit:config>

Dynamic Payload for Munit Test

This is how we can write a test case with a dynamic request payload. This will help to define a number of different input payloads based on the test scenario that can be used as a parameterized input.

XML

<ee:transform doc:name="payload" doc:id="7c934c10-d874-4207-be27-de6c8b1a1c5a" >
	<ee:message >
		<ee:set-payload >
			<![CDATA[%dw 2.0
output application/json
var fileBaseName = "-invalid-payload.json"
var caseNumber = Mule::p("caseNumber")
var fileName = caseNumber ++ fileBaseName
---
readUrl("classpath://test-data/employee/payload/$(fileName)", "application/json")]]>
		</ee:set-payload>
	</ee:message>
</ee:transform>

Test Output

We can test multiple field validation with a single munit test by using dynamic payload and parameterized input.

Code Reference

To find more on the above description, please follow the full code reference here.

Test case Test suite Testing Data Types

Opinions expressed by DZone contributors are their own.

Error Handling Inside Kumologica Subflow
How to Interpret the Number of Spring ApplicationContexts in Integration Tests
CI/CD Integration: Running Playwright on GitHub Actions: The Definitive Automation Blueprint
Apache Spark 3 to Apache Spark 4 Migration: What Breaks, What Improves, What's Mandatory

URL: https://dzone.com/articles/munit-parameterizations-tests