4 ms·

While I can easily see how this can be part of frontend development workflow, enabling "frontend-first" app development, TBH, I fail to see how this tool can be

While I can easily see how this can be part of frontend development workflow, enabling "frontend-first" app development, TBH, I fail to see how this tool can be helpful for testing purposes. Something like http://www.apilope.com/ http://www.apilope.com/ or https://uptimerobot.com/ https://uptimerobot.com/ do test the real thing, rather than a simple collection of mock templates.

Consultant32452 8y ago
Two totally different tools/purposes. Wiremock is not used to test your web service, it's mocking the web service so you can quickly code up your client work. In particular, this is useful if you will eventually be consuming web services which do not yet exist. You can quickly mock up some JSON/XML responses and hit them using real HTTP request and response.
- mahesh_rm 8y ago
  Indeed, you rephrased what I was saying. I fail to see how wiremock can help you "testing" your infrastructure (frontend in this case), as opposed to be saving you time during development of interfaces (use case that I can see it useful for).
  - Consultant32452 8y ago
    I'm afraid I may not clearly understand what you mean by "testing" then. I worked on one project where we used Wiremock extensively. Development and QA was done against the mocks because the real target system did not exist yet. Everything from business logic to error handling and even load testing was done against wiremock. Even when the other system got up and running, some conditions were impossible to test without wiremock. For example, what if the web service we hit returns a 500 error? Well, the real system never did that in practice. But with wiremock we could do that whenever we wanted. Of course, we still had to do integration testing before going live, but wiremock saved us a TON of time for development and QA.
    - mahesh_rm 8y ago
      "Development and QA was done against the mocks because the real target system did not exist yet." Wouldn't this be frontend discovery/development, rather than frontend testing? In this case, I recognize the tool can be useful. "For example, what if the web service we hit returns a 500 error?" Isn't this what development and staging environments are for? Not trying to be polemic/destructive, I just see building and maintaining mock api templates as a further overhead, when specific backend behavior can be simulated in an alternative deployment environment once a backend is in fact there. But maybe I don't fully understand the constraints posed by workflows other than mine! :-)
      - Consultant32452 8y ago
        You may not have any control whatsoever over the backend. You may not even have the ability to create data scenarios you want to test. Creating large/complex data scenarios is almost always more time intense than creating a mock. Honestly, creating simple data scenarios is almost always more time intense than creating a mock.

Consultant32452 8y ago

Two totally different tools/purposes. Wiremock is not used to test your web service, it's mocking the web service so you can quickly code up your client work. In particular, this is useful if you will eventually be consuming web services which do not yet exist. You can quickly mock up some JSON/XML responses and hit them using real HTTP request and response.

mahesh_rm 8y ago
Indeed, you rephrased what I was saying. I fail to see how wiremock can help you "testing" your infrastructure (frontend in this case), as opposed to be saving you time during development of interfaces (use case that I can see it useful for).
- Consultant32452 8y ago
  I'm afraid I may not clearly understand what you mean by "testing" then. I worked on one project where we used Wiremock extensively. Development and QA was done against the mocks because the real target system did not exist yet. Everything from business logic to error handling and even load testing was done against wiremock. Even when the other system got up and running, some conditions were impossible to test without wiremock. For example, what if the web service we hit returns a 500 error? Well, the real system never did that in practice. But with wiremock we could do that whenever we wanted. Of course, we still had to do integration testing before going live, but wiremock saved us a TON of time for development and QA.
  - mahesh_rm 8y ago
    "Development and QA was done against the mocks because the real target system did not exist yet." Wouldn't this be frontend discovery/development, rather than frontend testing? In this case, I recognize the tool can be useful. "For example, what if the web service we hit returns a 500 error?" Isn't this what development and staging environments are for? Not trying to be polemic/destructive, I just see building and maintaining mock api templates as a further overhead, when specific backend behavior can be simulated in an alternative deployment environment once a backend is in fact there. But maybe I don't fully understand the constraints posed by workflows other than mine! :-)
    - Consultant32452 8y ago
      You may not have any control whatsoever over the backend. You may not even have the ability to create data scenarios you want to test. Creating large/complex data scenarios is almost always more time intense than creating a mock. Honestly, creating simple data scenarios is almost always more time intense than creating a mock.