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.
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.
#%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: trueSample Request Payload
Based on the RAML definition, prepare a valid request payload.
{
"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.
<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.
<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.
<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.
Opinions expressed by DZone contributors are their own.