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.
Join the DZone community and get the full member experience.
Join For FreeThe 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
requiredtrue
minimum8
firstName
type string
requiredtrue
minLength1
maxLength10
pattern ^ A-Za-z *
lastName
type string
requiredtrue
minLength1
maxLength10
pattern ^ A-Za-z *
email
pattern ^.+@.+\..+$
gender
enum male female
default male
requiredtrue
dateOfBirh
type date-only
required true
addresses
type array
minItems1
items
type object
properties
isPermanent
type boolean
requiredtrue
street
type string
requiredtrue
minLength5
maxLength50
pattern ^ A-Za-z *
district
type string
requiredtrue
minLength3
maxLength20
pattern ^ A-Za-z *
state
type string
requiredtrue
minLength5
maxLength15
pattern ^ A-Za-z *
pinNumber
type integer
requiredtrue
minimum6
province
type string
requiredtrue
minLength1
maxLength10
pattern ^ A-Za-z *
phoneNumber
type string
requiredtrue
minLength1
maxLength13
pattern ^\s*|^(0|91)? 6-9 0-9 9 $
created
type datetime
format rfc3339
requiredtrue
createdDateTime
type datetime-only
requiredtrue
createdTime
type time-only
requiredtrue
Sample Request Payload
Based on the RAML definition, prepare a valid request payload.
{
"employeeId": 12345678,
"firstName": "Ankur",
"lastName": "Bhuyan",
"email": "ankur.bhuyan@gmail.com",
"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.
Comments