Wiremock Scenario- Not working on Jenkins pipeline
1,200 views
Skip to first unread message
thilmano_wiremockuser
Sep 8, 2021, 8:07:17 AM9/8/21
to wiremock-user
Hi,
I have implemented stateful behavior for the stubs using various scenario states. While testing locally, it works fine without any issues. However, when we build the wiremock using Jenking on a pipeline, the scenarios seems to be not working.
Anyone have come across such scenarios?? Please help
Thanks
thilmano_wiremockuser
Sep 9, 2021, 8:40:18 AM9/9/21
to wiremock-user
Hi..
Just thought of adding more specific details to the problems I face.. apologies, I missed it in the original post.
Wiremock Setup:
We use the standalone jar to build a docker image of wiremock server and run the image
All the above steps like building the image, moving the corresponding __files & mapping folders in the mounting directory, running the image etc are done using Jenkins pipeline script
Test Application:
We are using the Petclinic application to demonstrate the virtual backend services over a test pipeline
The Jenkins pipeline builds the Petclinic application by replacing the backend rest api with the Wiremock endpoint and run few sanity and acceptance tests.
Test Scenario:
Adding a Owner and verify it in the screen. To simulate this scenario, we used Wiremock stateful behavior, as below
1.) GET /api/owners call to list the set of Owners ->
requiredScenarioState : STARTED
2.) POST /api/owners call to add a owner ->
requiredScenarioState: STARTED,
newScenarioState: ADD NEW OWNER
3.) GET /api/owners call to list the set of Owners after adding a new Owner->
requiredScenarioState: ADD NEW OWNER
The above transactions works fine when run locally when integrated with the application- that is, by running Wiremock locally and configuring the wiremock end point in the application and building the Petclinic application locally
However, when we execute the same steps over a pipeline, the stateful scenario seems to be not working. Its work's as below (no error thrown)
1.) GET /api/owners call to list the set of Owners -> received Response-1 (expected behavior)
2.) POST /api/owners call to add a owner -> received Response-2 (expected behavior)
3.) GET /api/owners call to list the set of Owners after adding a new Owner-> received Respose-1 (not an expected behavior, was expecting Response-3)
which means, the stateful behavior is ignored for some reasons.
We tried "__admin/scenarios" to see any configuration misses after we run the wiremock in pipeline, but could find anything incorrect.
Thanks
Tom Akehurst
Sep 9, 2021, 8:49:57 AM9/9/21
to wiremock-user
Are you running the latest WireMock JRE8 version?
Can you share your actual stubs JSON and a snapshot of your request log (from http://localhost:8080/__admin/requests) from when you see the failure?
thilmano_wiremockuser
Sep 9, 2021, 10:11:43 AM9/9/21
to wiremock-user
Tom, we are running "wiremock-jre8-standalone-2.27.2.jar" (that's what is approved for us.. we are in the process of getting the latest jre jar approved by infosec)
Please find attached the request log and actual stubs.. it has all the necessary stubs..
FYI.. just noticed in the request logs that POST call with scenarios are not called at all.. not sure why
Tom Akehurst
Sep 9, 2021, 10:23:59 AM9/9/21
to wiremock-user
It looks like the POST stub on your CI system is being created without the scenario config. This is the request log event. If you look at the stubMapping section you'll see there are no scenario related attributes:
{
"id" : "c87f5959-511f-4fa9-8aa6-8bb4a15e1791",
"request" : {
"url" : "/petclinic/api/owners",
"absoluteUrl" : "http://petclinic-wiremock-qcoe-dev.tnt-001.tntnpk.az.fxei.fedex.com/petclinic/api/owners",
"method" : "POST",
"clientIp" : "10.205.205.74",
"headers" : {
"Origin" : "https://spring-petclinic-angular-development-qcoe-dev.tnt-001.tntnpk.az.fxei.fedex.com",
"Sec-Ch-Ua" : "\"Microsoft Edge\";v=\"93\", \" Not;A Brand\";v=\"99\", \"Chromium\";v=\"93\"",
"Accept" : "application/json, text/plain, */*",
"Sec-Ch-Ua-Platform" : "\"Windows\"",
"User-Agent" : "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36 Edg/93.0.961.38",
"Referer" : "https://spring-petclinic-angular-development-qcoe-dev.tnt-001.tntnpk.az.fxei.fedex.com/",
"X-Forwarded-Host" : "petclinic-wiremock-qcoe-dev.tnt-001.tntnpk.az.fxei.fedex.com",
"X-Forwarded-Proto" : "https",
"Sec-Fetch-Dest" : "empty",
"Sec-Fetch-Site" : "same-site",
"Accept-Encoding" : "gzip, deflate, br",
"X-Forwarded-Port" : "443",
"Sec-Fetch-Mode" : "cors",
"X-Forwarded-For" : "10.205.205.74",
"Accept-Language" : "en-GB,en;q=0.9,en-US;q=0.8",
"Content-Length" : "121",
"Sec-Ch-Ua-Mobile" : "?0",
"X-Real-Ip" : "10.205.205.74",
"X-Forwarded-Server" : "traefik-int-ingress-controller-7f8955587b-hx54m",
"Content-Type" : "application/json"
},
"cookies" : { },
"browserProxyRequest" : false,
"loggedDate" : 1631193841475,
"bodyAsBase64" : "eyJpZCI6bnVsbCwiZmlyc3ROYW1lIjoiU2VudGhpbCIsImxhc3ROYW1lIjoiU2h1bm11Z2EiLCJhZGRyZXNzIjoiMTQwMCBLb3ZpbmEiLCJjaXR5IjoiQ2hlbm5haSIsInRlbGVwaG9uZSI6Ijk4ODQzNjEwMTEifQ==",
"body" : "{\"id\":null,\"firstName\":\"Senthil\",\"lastName\":\"Shunmuga\",\"address\":\"1400 Kovina\",\"city\":\"Chennai\",\"telephone\":\"9884361011\"}",
"scheme" : "http",
"port" : -1,
"loggedDateString" : "2021-09-09T13:24:01Z",
"queryParams" : { }
},
"responseDefinition" : {
"status" : 201,
"body" : "{\n \"address\": \"lake view road\",\n \"city\": \"new york\",\n \"firstName\": \"Mark\",\n \"id\": 7,\n \"lastName\": \"Peters\",\n \"pets\": [\n {\n \"birthDate\": \"2021-05-11T09:12:23.679Z\",\n \"id\": 1,\n \"name\": \"Hoffman\",\n \"type\": {\n \"id\": 1,\n \"name\": \"Doggie\"\n },\n \"visits\": [\n {\n \"date\": \"2021/05/03\",\n \"description\": \"Doggie was visited\",\n \"id\": 1\n }\n ]\n }\n ],\n \"telephone\": \"8008015463\"\n}\n",
"bodyFileName" : "body-v2-petclinic-apiOwnersPost.json",
"headers" : {
"Access-Control-Allow-Origin" : "*",
"Access-Control-Allow-Credentials" : "true",
"Access-Control-Allow-Methods" : "POST, GET, OPTIONS, PUT, DELETE",
"Access-Control-Allow-Headers" : "*",
"Access-Control-Max-Age" : "86400",
"cache-control" : "no-cache, no-store, max-age=0, must-revalidate",
"content-type" : "application/json",
"pragma" : "no-cache",
"strict-transport-security" : "max-age=315360000; includeSubDomains; preload",
"vary" : "Origin, Access-Control-Request-Method, Access-Control-Request-Headers",
"x-content-type-options" : "nosniff",
"x-frame-options" : "DENY",
"x-xss-protection" : "1; mode=block"
}
},
"response" : {
"status" : 201,
"headers" : {
"Access-Control-Allow-Origin" : "*",
"Access-Control-Allow-Credentials" : "true",
"Access-Control-Allow-Methods" : "POST, GET, OPTIONS, PUT, DELETE",
"Access-Control-Allow-Headers" : "*",
"Access-Control-Max-Age" : "86400",
"cache-control" : "no-cache, no-store, max-age=0, must-revalidate",
"content-type" : "application/json",
"pragma" : "no-cache",
"strict-transport-security" : "max-age=315360000; includeSubDomains; preload",
"vary" : "Origin, Access-Control-Request-Method, Access-Control-Request-Headers",
"x-content-type-options" : "nosniff",
"x-frame-options" : "DENY",
"x-xss-protection" : "1; mode=block",
"Matched-Stub-Id" : "ad746870-f3d6-4048-acb8-ef1da3b6e923"
},
"bodyAsBase64" : "ewogICJhZGRyZXNzIjogImxha2UgdmlldyByb2FkIiwKICAiY2l0eSI6ICJuZXcgeW9yayIsCiAgImZpcnN0TmFtZSI6ICJNYXJrIiwKICAiaWQiOiA3LAogICJsYXN0TmFtZSI6ICJQZXRlcnMiLAogICJwZXRzIjogWwogICAgewogICAgICAiYmlydGhEYXRlIjogIjIwMjEtMDUtMTFUMDk6MTI6MjMuNjc5WiIsCiAgICAgICJpZCI6IDEsCiAgICAgICJuYW1lIjogIkhvZmZtYW4iLAogICAgICAidHlwZSI6IHsKICAgICAgICAiaWQiOiAxLAogICAgICAgICJuYW1lIjogIkRvZ2dpZSIKICAgICAgfSwKICAgICAgInZpc2l0cyI6IFsKICAgICAgICB7CiAgICAgICAgICAiZGF0ZSI6ICIyMDIxLzA1LzAzIiwKICAgICAgICAgICJkZXNjcmlwdGlvbiI6ICJEb2dnaWUgd2FzIHZpc2l0ZWQiLAogICAgICAgICAgImlkIjogMQogICAgICAgIH0KICAgICAgXQogICAgfQogIF0sCiAgInRlbGVwaG9uZSI6ICI4MDA4MDE1NDYzIgp9Cg==",
"body" : "{\n \"address\": \"lake view road\",\n \"city\": \"new york\",\n \"firstName\": \"Mark\",\n \"id\": 7,\n \"lastName\": \"Peters\",\n \"pets\": [\n {\n \"birthDate\": \"2021-05-11T09:12:23.679Z\",\n \"id\": 1,\n \"name\": \"Hoffman\",\n \"type\": {\n \"id\": 1,\n \"name\": \"Doggie\"\n },\n \"visits\": [\n {\n \"date\": \"2021/05/03\",\n \"description\": \"Doggie was visited\",\n \"id\": 1\n }\n ]\n }\n ],\n \"telephone\": \"8008015463\"\n}\n"
},
"wasMatched" : true,
"timing" : {
"addedDelay" : 0,
"processTime" : 6,
"responseSendTime" : 1,
"serveTime" : 7,
"totalTime" : 7
},
"stubMapping" : {
"id" : "ad746870-f3d6-4048-acb8-ef1da3b6e923",
"request" : {
"url" : "/petclinic/api/owners",
"method" : "POST"
},
"response" : {
"status" : 201,
"bodyFileName" : "body-v2-petclinic-apiOwnersPost.json",
"headers" : {
"Access-Control-Allow-Origin" : "*",
"Access-Control-Allow-Credentials" : "true",
"Access-Control-Allow-Methods" : "POST, GET, OPTIONS, PUT, DELETE",
"Access-Control-Allow-Headers" : "*",
"Access-Control-Max-Age" : "86400",
"cache-control" : "no-cache, no-store, max-age=0, must-revalidate",
"content-type" : "application/json",
"pragma" : "no-cache",
"strict-transport-security" : "max-age=315360000; includeSubDomains; preload",
"vary" : "Origin, Access-Control-Request-Method, Access-Control-Request-Headers",
"x-content-type-options" : "nosniff",
"x-frame-options" : "DENY",
"x-xss-protection" : "1; mode=block"
}
},
"uuid" : "ad746870-f3d6-4048-acb8-ef1da3b6e923"
}
}
thilmano_wiremockuser
Sep 9, 2021, 10:30:35 AM9/9/21
to wiremock-user
yes Tom, I noticed that while reviewing the request logs.
Has anyone reported such issues??
Any idea why the scenario config is ignored in the CI systems?? I will try and share the pipeline script ASAP
Tom Akehurst
Sep 9, 2021, 10:53:45 AM9/9/21
to wiremock-user
I'd suggest probing how your stubs are being created a bit more closely. One possibility is that there are two versions of the POST stub being created, one with scenario information and one without. The ordering may be arbitrary and depend on the platform or timing, so in one case you get the good one at the top of the list and in the other you get the bad one.
thilmano_wiremockuser
Sep 10, 2021, 1:51:12 AM9/10/21
to wiremock-user
Tom.. yes I do have 2 POST stubs...one with the Scenario and the other one without.
The reason for that is, once the user adds a data and verify it by retrieving in the grid, the first scenario gets over. But, after these steps if the user tries to add again, the stub breaks, because there is no POST call without scenario. So to eliminate this possibility, I had a POST call without scenario to handle the unforeseen scenario.
While writing this, I am getting a thought, where I can have a "Catch All" kind of stub to handle this scenario instead of a POST call. Let me try that and get back to you with observations
Thanks
Tom Akehurst
Sep 10, 2021, 4:25:19 AM9/10/21
to wiremock-user
It's possible to have a catch-all stub (using low priority and broad matching), but I'd be careful about using that approach as I think it could get confusing when test conditions change. I'd normally suggest having only one POST stub that advances the scenario and ensuring the the matching is loose enough to ensure it's triggered correctly for your test case.
thilmano_wiremockuser
Sep 13, 2021, 4:19:16 AM9/13/21
to wiremock-user
Hi Tom, in my test scenario, having 1 POST call seems to be not feasible.. So I just played around with setting up priorities for the stubs with POST call and adjusted a bit of match criteria... seems to be working now (for the specific test case)
If I get more scenarios, then I may have to revisit this approach... anyway thanks for your suggestion..
Thanks
Senthil Manohar
Reply all
Reply to author
Forward
0 new messages