A tool for mocking HTTP services

Overview

WireMock - a web service test double for all occasions

Build Status Maven Central

Key Features

  • HTTP response stubbing, matchable on URL, header and body content patterns
  • Request verification
  • Runs in unit tests, as a standalone process or as a WAR app
  • Configurable via a fluent Java API, JSON files and JSON over HTTP
  • Record/playback of stubs
  • Fault injection
  • Per-request conditional proxying
  • Browser proxying for request inspection and replacement
  • Stateful behaviour simulation
  • Configurable response delays

Full documentation can be found at wiremock.org

Questions and Issues

If you have a question about WireMock, or are experiencing a problem you're not sure is a bug please post a message to the WireMock mailing list.

On the other hand if you're pretty certain you've found a bug please open an issue.

Contributing

We welcome bug fixes and new features in the form of pull requests. If you'd like to contribute, please be mindful of the following guidelines:

  • All changes should include suitable tests, whether to demonstrate the bug or exercise and document the new feature.
  • Please make one change per pull request.
  • If the new feature is significantly large/complex/breaks existing behaviour, please first post a summary of your idea on the mailing list to generate a discussion. This will avoid significant amounts of coding time spent on changes that ultimately get rejected.
  • Try to avoid reformats of files that change the indentation, tabs to spaces etc., as this makes reviewing diffs much more difficult.

Building WireMock locally

To run all of WireMock's tests:

./gradlew clean test

To build both JARs (thin and standalone):

./gradlew -c release-settings.gradle :java8:shadowJar

The built JAR will be placed under java8/build/libs.

Developing on IntelliJ IDEA

IntelliJ can't import the gradle build script correctly automatically, so run

./gradlew -c release-settings.gradle :java8:idea

Make sure you have no .idea directory, the plugin generates old style .ipr, .iml & .iws metadata files.

You may have to then set up your project SDK to point at your Java 8 installation.

Then edit the module settings. Remove the "null" Source & Test source folders from all modules. Add wiremock as a module dependency to Java 7 & Java 8.

Comments
  • PUT stub seems to fail if test method runs too fast

    PUT stub seems to fail if test method runs too fast

    Hi - I am using version 1.42, and am using JUnit 4 and the SpringJUnit4ClassRunner.

    I have a JUnit test case in which I have created a number of test cases that establish GET mappings, all of which work when the test class is run. However, when I add a PUT mapping (the URL is very similar but not identical to the GETs) it often fails with a read connect timeout. Although other times it succeeds quite rapidly. What I've found is that if I do a Thread.sleep(5000) at the beginning of the test method, it works consistently.

    Could the start-up of the server not be fully complete when the test method begins? Maybe the SpringJUnit4ClassRunner is not waiting for the rule to be fully initialized.

    Have you ever encountered an issue like this?

    bug 
    opened by joegluntz 135
  • WireMock with JUnit 5

    WireMock with JUnit 5

    In JUnit 5, @Rule and @ClassRule is superseded by @ExtendWith, which requires extension class. And it seems like extension for WireMock is not yet supported. Is there any alternative way to use WireMock with stubbing and verification via JUnit 5?

    enhancement 
    opened by wonha 64
  • Spring WebFlux reactive threads hanging, required Jetty 9.4.x

    Spring WebFlux reactive threads hanging, required Jetty 9.4.x

    Wiremock is using a version of Jetty 9.2.x and for the new version of Spring Boot with the WebFlux (2.0.0.RELEASE) Reactive threads sometimes the calling thread stops and hanging when calling Wiremock. This problem occurs only in version 9.2.x and not in 9.4.8.v20171121 of Jetty.

    I understand that you want the JDK 7 support, but in that case you'll lose support for newer technologies/frameworks like Spring WebFlux, HTTP2 and so on... Wiremock with version 9.2.x of Jetty is unusable with reactive threads because it randomly stops hanging.

    I saw your conversation on https://github.com/tomakehurst/wiremock/pull/887 thread and the commit https://github.com/tomakehurst/wiremock/commit/4368d316ec239bac305f1faadedab24765bbe4b6, but somehow it will be very nice if you can provide support for the new Spring 5 WebFlux (Spring Boot WebFlux 2.0.0.RELEASE).

    Add another JAR artifact to the build that's Java 8+ only and uses the latest Jetty version. This would probably involve splitting the source tree up into core and version-specific parts, which the build would include/exclude for the various output JARs.

    Add some runtime detection of the environment i.e. are we on Java 8+ and Jetty 9.4+, and load the HTTP/2 code only under these conditions, such that NoClassDefFoundErrors and the like aren't thrown when running on Java 7.

    Any of the above solution should be fine. The idea is to upgrade also the Wiremock Standalone which is used by spring-cloud-contract-wiremock.

    Please see related issues: https://github.com/spring-projects/spring-boot/issues/10569 https://github.com/reactor/reactor-netty/issues/264 https://github.com/spring-cloud/spring-cloud-contract/issues/606

    opened by ati90ati 62
  • Unexpected end of file from server exception when several test methods within one class

    Unexpected end of file from server exception when several test methods within one class

    This doesn't seem to be a problem on my own computer. However when I run the maven build on Jenkins, it always fails with the following message: Caused by: java.net.SocketException: SocketException invoking http://localhost:8098/some/useless/path: Unexpected end of file from server.

    I searched Wiremock's config, it doesn't seem that I can change the server timeout settings.

    bug 
    opened by tongguop 57
  • Request matching with dynamic dates

    Request matching with dynamic dates

    Feature request

    As discussed with Tom via the mailing list...

    We're looking to be able to request match on a dynamic date. We have a few calls which always have a date a number of days in the future from the present date. So ideally we want to be able to use the date helper in the request matching.

    e.g.

      "priority": 5,
      "request": {
        "method": "POST",
        "url": "/api/service/fetchPolicy",
        "bodyPatterns": [
          {
            "matchesXPath": "//*[local-name() = 'PolicyNumber' and @Val = 'pol123456']"
          },
          {
            "matchesXPath": "//*[local-name() = 'StartDate' and @Val = '{{now offset=\'30 days\' format=\'yyyy-MM-dd\'}}']"
          }
        ]
      }
    

    Being able to use the full range of options within the date and time response templating helper to set the time/date in different formats, offset by days, hours, minutes etc would be ideal.

    enhancement 
    opened by andy-cross 43
  • Issue #546 - New API endpoint for recording stub mappings

    Issue #546 - New API endpoint for recording stub mappings

    As promised, here's a PR that integrates my wiremock-snapshot extension. It adds a new API endpoint, /__admin/snapshot, for recording stub mappings from the request journal. The README has more details, but here's a summary of the options it accepts:

    • "filters" - Request patterns to use for determining the requests for which to create stub mappings.
      • Possible values: Identical to /__admin/requests/find
      • Default: no filtering.
    • "persist" - If set to true, persist stub mappings to disk. Otherwise, just output them.
      • Possible values: true, false
      • Default: true
    • "sortFields" - Array of fields in the request to use for sorting stub mappings, mainly for output.
      • Possible values: "url", "method", or a header name (e.g. "Accept")
      • Default: no sorting.
    • "captureHeaders" - Header matchers for including headers in the stub mapping. The request is matched against each matcher, and the associated header is added to the stub mapping if there's a match.
      • Possible values: Request matchers for headers.
      • Default: none
    • "outputFormat" - Determines response body.
      • Possible values: "ids" to return array of stub mapping IDs, "full" to return array of stub mapping objects
      • Default: "ids"

    Design issues

    Filtering

    Filtering is currently request-only. I'm not sure if response filtering is desired. If so, we'd probably want to add a new ResponsePattern class (analogous to ResponsePattern) to encapsulate matchers for the response. This would be best accompanied with some refactoring to make Response into a an interface implemented by LoggedResponse .

    Body file extraction/naming

    Currently, the API does not extract the response bodies to a separate file. While it'd be easy to add a flag to enable this, I think more granularity is needed. Body file extraction is useful for large binary responses, but generally undesirable for small JSON responses. Perhaps we can add a "bodyFileCritera" option consisting of matchers that determine whether or not to extract the body. That way, you could use "headers": { "Content-Type": { "doesNotMatch": ".*json.*" } } } to only extract non-JSON responses. Again, we'll probably want to add a ResponsePattern class for this, and a "bodySize" matcher to allow matching by the size of the body.

    Uniqueness/Deduplication

    To ensure stub mappings are unique, I have StubMappingTransformer#apply() generate a MD5 hash of the RequestPattern JSON and set that as the UUID. This is pretty hacky, but it seems to work well. I considered just using hashCode(), but that's not appropriate since it has a high collision probability and the result is not guaranteed to be consistent between executions (see the JavaDoc).

    This makes me wonder why StubMapping IDs are random instead of being a content-based hash. I see this was added in PR #306, but it doesn't seem uniqueness was considered.

    Outputting

    The options available in "outputFormat" seem sufficient to me. If we add body file extraction, we may want to add another output format to serve everything in a zip file.

    Sorting

    I implemented the ability to sort the stub mappings by the request URL, method, or a header. The main use case for this is to make it easier to manually edit the stub mappings. This is arguably better served by extension points, so it might be better to just remove this feature.

    The class used for sorting, RequestFieldsComparator, is pretty hacky and a violation of the open-closed principle, but I couldn't think of a better implementation.

    Extension points

    An extension point for modifying StubMapping objects would be easy to add. Specifically, we could have WireMockApp#buildAdminRequestHandler() pass in the stub mapping extensions along with the API extensions to AdminRoutes, which could then call

    router.add(POST, "/snapshot", new SnapshotTask(this.stubMappingTransformerExtensions));
    

    instead of

    router.add(POST, "/snapshot", SnapshotTask.class);
    

    Adding the ability to customize the file names for persisted mappings would be more complex. Perhaps we could use a wrapper class, e.g. RecordedStubMapping, that would allow extensions to set the name for the mapping file and (if applicable) the body file.

    Statefulness/Scenarios

    It'd be easy to detect duplicate requests and then set the StubMapping scenario name, but I'm not quite sure about naming. We could just use something like UniqueFilenameGenerator to auto-generate the scenario name, but we'll probably want to have some way of customizing it. Maybe a "scenarioNameTemplate" option that accepts a Handlebars template?

    edit: Minor clarifications

    opened by MasonM 34
  • Add a plugin/extension mehanism

    Add a plugin/extension mehanism

    I've previously forked (privately inside a company) to add support for things like proprietary auth mechanisms. I'd rather just take master version + add things to the class path.

    I was thinking of adding an interface something like:

    package com.github.tomakehurst.wiremock.http;
    
    public interface RequestResponseExtension {
        ResponseDefinition filter(Request request, ResponseDefinition responseDefinition);
    }
    

    Then loading all implementations off the class path using https://github.com/ronmamo/reflections (or perhaps java service loader api but this is more work for people providing extensions)

    These could then be picked up in the StubRequestHandler and each request/response passed through?

    I wasn't planning on adding a way to prime them and just have them all picked up and used by default?

    What do you think?

    opened by chbatey 30
  • proxy forwarding using SSL - feature request

    proxy forwarding using SSL - feature request

    First, i apologize if this is not the right place for a request.

    Secondly, I know that from a previous threads this is not allowed per design: https://github.com/tomakehurst/wiremock/issues/62 and https://github.com/tomakehurst/wiremock/issues/139

    Ah, no that's correct - you can't forward proxy onto SSL. This is a general limitation, as the whole point in SSL is preventing man-in-the-middle attacks.

    Is there a way to add this? maybe something like --enable-browser-proxying-with-ssl?

    It would be great to proxy everything from our IIS to it and have to forward all requests to the original endpoint, unless we post an overide for a specific url which WireMock could mock. Our endpoints are about 50% SSL and about 50% non SSL.

    enhancement 
    opened by txjohng 25
  • Create new client every time, to work around obscure and I/O-level multi-threading issues

    Create new client every time, to work around obscure and I/O-level multi-threading issues

    Yes, it's true. On OSX, I encountered an obscure bug.

    To uncover it, I added print statements that I implemented by decorating breakpoints in IDEA:

    This is all in apache's httpcore version 4.4.1. In org.apache.http.protocol.HttpRequestExecutor, I added non-suspending and logging breakpoints as follows:

    Line 122: "REQ: " + System.identityHashCode(conn) + ": " + conn + " => " + request Line 126: "OK: " + System.identityHashCode(conn) + ": " + conn + " => " + request Line 128: "FAIL: " + System.identityHashCode(conn) + ": " + conn + " => " + request + ": " + ex

    A typical output, which shows the bug at the end:

    REQ: 120493608: CPoolProxy{148.121.152.75:56553<->10.179.121.244:8084} => [URL] REQ: 1402900645: CPoolProxy{148.121.152.75:56552<->10.179.121.244:8084} => [URL] OK: 120493608: CPoolProxy{148.121.152.75:56553<->10.179.121.244:8084} => [URL] OK: 1402900645: CPoolProxy{148.121.152.75:56552<->10.179.121.244:8084} => [URL] REQ: 1848886687: CPoolProxy{148.121.152.75:56552<->10.179.121.244:8084} => [URL] FAIL: 1848886687: CPoolProxy{0:0:0:0:0:0:9479:984b:56552<->10.179.121.244:8084} => [URL]: org.apache.http.NoHttpResponseException: The target server failed to respond

    (The [URL]'s are request objects I have edited out, for clarity.)

    The System.identityHashCodes ensure I am printing the same object. We see object #1848886687 goes from one state at request time, and to a new state after. The new state is that the local address has mysteriously become 0:0:0:0:0:0:9479:984b!

    What is that, you say? It is an IPv6 address format. However, it describes the same IPv4 IP address! You can work out what 94.79.98.4b is in decimal for yourself ...

    When does this change occur? When the socket connection flushes the outgoing data. (I.e. the request.) This happens in org.apache.http.impl.io.SessionOutputBufferImpl, line 126:

       this.outstream.write(b, off, len);
    

    Don't ask me how it happens, but before we call write here, the connection is fine. And SOMETIMES, when the call returns, it is screwed, and unable to receive incoming data. (Manifesting as NoHttpResponseException: The target server failed to respond, as above, and the FAIL breakpoint hitting.) Not every time, but pretty often. This is why I suspect multi-threading issues.

    I am serious. Do NOT ask me how this happens. Could be an issue with http-core and/or my network setup. I just know the pull request makes the FAILs go away.

    PS: Sorry about the whitespace/formatting diff, that's my opinionated IDEA. The change is only creating a new client every time. I can clean that up, but it'll have to be a little later.

    PPS: This is NOT an april fool's!

    opened by kjetilv 24
  • GZIP compression does not work for responses to POST requests.

    GZIP compression does not work for responses to POST requests.

    Wiremock registers GzipFilter with default configuration:

    com.github.tomakehurst.wiremock.jetty9.JettyHttpServer
    
    mockServiceContext.addFilter(GzipFilter.class, "/*", EnumSet.of(DispatcherType.REQUEST, DispatcherType.FORWARD));
    

    But by default the aforementioned filter handles only GET request.

    org.eclipse.jetty.servlets.GzipFilter
    
    // public void init
    tmp=filterConfig.getInitParameter("methods");
            if (tmp!=null)
            {
                StringTokenizer tok = new StringTokenizer(tmp,",",false);
                while (tok.hasMoreTokens())
                    _methods.add(tok.nextToken().trim().toUpperCase(Locale.ENGLISH));
            }
            else
                _methods.add(HttpMethod.GET.asString());
    
    // public void doFilter()
    if (!_methods.contains(request.getMethod()) || isExcludedPath(requestURI))
            {
                super.doFilter(request,response,chain);
                return;
            }
    
    enhancement 
    opened by arokhmistrov 23
  • Support for parametrization in reponse body files via Velocity templates.

    Support for parametrization in reponse body files via Velocity templates.

    Hi Tom , hope all is well.

    Recently I had the need to support parametrization in stubbed service calls. Essentially I was stubbing part of a user registration flow and using JMeter to help load test.The flow requires a unique user guid to be passed in, and it in turn does a look up on this id, and generates a hash derived from the guid passed via the request. Because I am using an incrementer from within a JMeter plan and invoking tens of thousands of requests concurrently, I was having to generate tens of thousands of mocks. A wild card, catch all response mapping would not work in this scenario.

    I added in support for Velocity templates. The request is processed in the handler , and stored in a context object. Before the response is rendered , I do a check to see if the body file is of type .vm , if so the context object is merged with template, and I can process or extrapolate information from the request into the response dynamically.

    Thought perhaps this may benefit others.

    Cheers ! -adam

    opened by adamyork 22
  • Problems with CONNECT requests

    Problems with CONNECT requests

    The problem

    Hi while trying to change WireMock to work with traffic in integration tests without the need to override base urls I've encountered a following problem. In one of services we are using reactor netty http client and this lead to an exception that was not observed on other services. I've learned that this one client despite http protocol uses CONNECT requests while creating tunnel https://github.com/netty/netty/issues/10475. It was causing similar issues to the ones I've had on other services while trying to use https requests through WireMock (server was configured based on documentation to accept https requests). This lead me to wonder that WireMock might not be handling CONNECT requests, or something around it, well.

    Setup

    • version - com.github.tomakehurst:wiremock-jre8:2.34.0
    • example - https://github.com/lzolkiewski/wiremock-connect-problem

    Feature requests

    I'd like to be able to use netty's httpClient with WireMock when it works as a proxy. Also I'd like WireMock to handle well requests that require CONNECT request.

    Details

    Before update to the latest version I was prompted to match CONNECT requests by hand, since though following exception is being thrown while using netty HttpClient:

    org.opentest4j.AssertionFailedError: expected: <null> but was: <reactor.core.Exceptions$ReactiveException: reactor.netty.http.client.PrematureCloseException: Connection prematurely closed BEFORE response>
    	at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
    	at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
    	at app//org.junit.jupiter.api.AssertNull.failNotNull(AssertNull.java:50)
    	at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:35)
    	at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:30)
    

    Through Wireshark following can be seen: image image image image image image image

    Thank you for any guidance

    opened by lzolkiewski 1
  • Bump versions.junitJupiter from 5.9.0 to 5.9.1

    Bump versions.junitJupiter from 5.9.0 to 5.9.1

    Bumps versions.junitJupiter from 5.9.0 to 5.9.1. Updates junit-bom from 5.9.0 to 5.9.1

    Release notes

    Sourced from junit-bom's releases.

    JUnit 5.9.1 = Platform 1.9.1 + Jupiter 5.9.1 + Vintage 5.9.1

    See Release Notes.

    Commits
    • 732a540 Release 5.9.1
    • 88bf48d Prepare release notes for 5.9.1
    • d75e34d Update scope for 5.9.1
    • 9823f73 Link to all 5.9 milestone pages
    • 76719bb Increase timeout for GraalVM test
    • 2a80984 Install GraalVM for main CI build on Linux
    • 79f47f5 Refactor OpenTestReportGeneratingListener to work in native images
    • 7229385 Add failing integration test for execution on GraalVM native image
    • 343170f Fix running tests in documentation from IntelliJ IDEA
    • 352d06b Attempt to stabilize test on Windows
    • Additional commits viewable in compare view

    Updates junit-jupiter from 5.9.0 to 5.9.1

    Release notes

    Sourced from junit-jupiter's releases.

    JUnit 5.9.1 = Platform 1.9.1 + Jupiter 5.9.1 + Vintage 5.9.1

    See Release Notes.

    Commits
    • 732a540 Release 5.9.1
    • 88bf48d Prepare release notes for 5.9.1
    • d75e34d Update scope for 5.9.1
    • 9823f73 Link to all 5.9 milestone pages
    • 76719bb Increase timeout for GraalVM test
    • 2a80984 Install GraalVM for main CI build on Linux
    • 79f47f5 Refactor OpenTestReportGeneratingListener to work in native images
    • 7229385 Add failing integration test for execution on GraalVM native image
    • 343170f Fix running tests in documentation from IntelliJ IDEA
    • 352d06b Attempt to stabilize test on Windows
    • Additional commits viewable in compare view

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies java 
    opened by dependabot[bot] 0
  • Bump slf4j-api from 2.0.1 to 2.0.2

    Bump slf4j-api from 2.0.1 to 2.0.2

    Bumps slf4j-api from 2.0.1 to 2.0.2.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies java 
    opened by dependabot[bot] 0
  • Jetty 10 support

    Jetty 10 support

    The Jetty 10 is the next (last?) javax.* compatible release branch: JDK 11 base line, new APIs. It woud be great to have wiremock to support Jetty 10, along with Jetty 9 (and Jetty 11 [1]).

    @tomakehurst wdyt? Once we done with Jetty 11 [1], we could also work on supporting Jetty 10, preferably alongside with Jetty 9, so wiremock could be used in wider range of applications (should be easier at least with respect to fileupload).

    [1] https://github.com/wiremock/wiremock/issues/1760

    opened by reta 4
  • Bump scala-library from 2.13.8 to 2.13.9

    Bump scala-library from 2.13.8 to 2.13.9

    Bumps scala-library from 2.13.8 to 2.13.9.

    Commits
    • 986dcc1 Merge pull request #10129 from som-snytt/followup/12586-preserve-NPE
    • b824b84 Preserve null policy in wrapped Java Map
    • d578a02 Merge pull request #10128 from SethTisue/revert-10114-10123
    • e5fe919 Revert "Args files are 1 arg per line, fix -Vprint-args -"
    • 362c5d1 Revert "Trim and filter empties in arg files"
    • 864148d Revert "process.Parser strips escaping backslash"
    • f69fe8b Merge pull request #10127 from scalacenter/tasty/support-3.2.0-final
    • 0aa6bd4 remove tasty escape hatch for 3.2.0-RC4
    • af56abc Merge pull request #10123 from som-snytt/dev/814-window-cmd-escapes
    • 7e844a5 Merge pull request #10121 from scala-steward/update/slf4j-nop-2.0.0
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies java 
    opened by dependabot[bot] 0
  • Downgrade SLF4J to 1.7.x

    Downgrade SLF4J to 1.7.x

    Fixes https://github.com/wiremock/wiremock/issues/1964

    Versions 1.8.x and 2.x are incompatible with older versions. The vast majority of Java libraries are still using 1.7.x.

    This PR downgrades SLF4J to the latest 1.7.x and updates the dependabot configuration to prevent upgrades to the 1.8.x and 2.x versions.

    opened by pkoenig10 0
Releases(2.34.0)
  • 2.34.0(Sep 15, 2022)

    This will be the final 2.x.x release and also the last to support Java 8.

    Fixes

    • Fixed #1689 - incorrect HTTP version header - thanks to user Poojitha
    • Fixed #1882 - bug preventing matching of date/time query params/headers with custom format - thanks Klaas Dellschaft
    • #1930 - Fixed a partial path traversal vulnerability in the file source code - thanks Jonathan Leitschuh
    • Fixed #1783 - proxyUrlPrefixToRemove ignored when using a response definition transformer - thanks to user Ross-H-Projects
    • Fixed #1872 - create a request entity for POST, PUT etc. proxied requests when a content-length header is present, regardless of whether the size is 0.
    • Fixed #1946 - maths helper now supports epoch dates as inputs.

    Enhancements

    • Added a public, non-static getScenarios() method allowing access to all scenarios.

    All dependencies brought up to date including Jetty to 9.4.48.v20220622.

    Source code(tar.gz)
    Source code(zip)
  • 2.33.2(Apr 29, 2022)

    WireMock 2.33.1 was accidentally released using Java 11 rather than 8, resulting in class incompatibilities in places.

    This release is functionally identical but built using Java 8.

    Source code(tar.gz)
    Source code(zip)
  • 2.33.1(Apr 9, 2022)

    Fixes

    • Put name field back on scenario API object having accidentally removed it.
    • Improved validation of scenario set and reset so that reasonable errors are returned when attempting to use non-existent scenario names or states.
    Source code(tar.gz)
    Source code(zip)
  • 2.33.0(Apr 8, 2022)

    This is primarily a maintenance release that brings all dependency versions up to date including a version of Jackson containing the fix for CVE-2020-36518.

    Enhancements

    • Added the ability to set and reset a single scenario's state
    • Proxy will now send a request body for any request method.
    • CORS response headers are now passed back from proxy responses when stub CORS is disabled.

    Performance

    • Improved performance of Request.getHeaders() - thanks Doug Roper.
    • Improved performance of response body JSON parsing - thanks also Doug Roper.
    Source code(tar.gz)
    Source code(zip)
  • 2.32.0(Dec 2, 2021)

    Enhancements

    • Closes #1614 - proper support for subclassing of the JUnit5 WireMockExtension
    • Add support for put/delete file to/from a subfolder (#1087)
    • Closes #956 - added the ability to fetch serve events for a specific stub ID
    • Added ability to query unmatched serve events
    • Added ability to verify requests using a custom matcher
    • Upgraded to Apache HTTP Client 5.x
    • Added WireMock.jsonResponse factory methods (#1428)
    • #745 Need proxyUrlPrefixToRemove for proxy context url mapping (#1556)
    • Removed dependence on Conscrypt for ALPN and HTTP/2
    • Recognize multipart/related and multipart/mixed (#1415)
    • Allow running Wiremock without HTTP Server (#1572)
    • Allow standalone runner to fetch mappings from classpath (#1592)
    • Added new command line parameters "--jetty-header-request-size" and "--jetty-header-response-size" for set a custom size of headers in Jetty. "--jetty-header-buffer-size" is deprecated.

    Fixes

    • Closes #1688 - fall back to HTTPS 1.1 only when no ALPN provider can be loaded
    • Fixed #1643 - regression in date parsing preventing year and year/month only dates
    • #1612 prevent applying scientific notation and rounding to big numbers by ObjectMapper (#1613)
    • Fixed #1608 and #1585 - incorrect zoning of date/times in response templating when truncating

    Code quality

    • Enforce license headers with Spotless
    • Enforce consistent code style with Spotless
    • Upgrade to Gradle 7 + some Gradle config cleanup (#1639)
    • Convert AcceptanceTestBase to JUnit Jupiter to limit future violations (#1669)
    • Enable WireMock to be built on Java 11 and 17
    • Drop JMock in favour of Mockito (#1630)
    Source code(tar.gz)
    Source code(zip)
Owner
Tom Akehurst
Tom Akehurst
MockServer enables easy mocking of any system you integrate with via HTTP or HTTPS with clients written in Java, JavaScript and Rub

MockServer enables easy mocking of any system you integrate with via HTTP or HTTPS with clients written in Java, JavaScript and Ruby. MockServer also includes a proxy that introspects all proxied traffic including encrypted SSL traffic and supports Port Forwarding, Web Proxying (i.e. HTTP proxy), HTTPS Tunneling Proxying (using HTTP CONNECT) and SOCKS Proxying (i.e. dynamic port forwarding).

Mock-Server 3.9k Oct 2, 2022
Most popular Mocking framework for unit tests written in Java

Most popular mocking framework for Java Current version is 3.x Still on Mockito 1.x? See what's new in Mockito 2! Mockito 3 does not introduce any bre

mockito 13.3k Oct 3, 2022
Advanced Java library for integration testing, mocking, faking, and code coverage

Codebase for JMockit 1.x releases - Documentation - Release notes How to build the project: use JDK 1.8 or newer use Maven 3.6.0 or newer; the followi

The JMockit Testing Toolkit 433 Sep 11, 2022
Gatling is a load test tool. It officially supports HTTP, WebSocket, Server-Sent-Events and JMS.

Gatling What is Gatling ? Gatling is a load test tool. It officially supports HTTP, WebSocket, Server-Sent-Events and JMS. Motivation Finding fancy GU

Gatling 5.7k Oct 2, 2022
Java DSL for easy testing of REST services

Testing and validation of REST services in Java is harder than in dynamic languages such as Ruby and Groovy. REST Assured brings the simplicity of usi

REST Assured 6k Oct 5, 2022
Cucumber DSL for testing RESTful Web Services

cukes-rest takes simplicity of Cucumber and provides bindings for HTTP specification. As a sugar on top, cukes-rest adds steps for storing and using r

C.T.Co 99 Aug 13, 2022
Java DSL for easy testing of REST services

Testing and validation of REST services in Java is harder than in dynamic languages such as Ruby and Groovy. REST Assured brings the simplicity of usi

REST Assured 6k Oct 1, 2022
Sikuli's official repository on github. Ask questions or report bugs at http://launchpad.net/sikuli.

!!!This Sikuli X-1.0rc3 IS NO LONGER SUPPORTED !!! A new version of Sikuli(X) is available since 2013 as a follow up development GitHub repo: RaiMan/S

Sikuli Lab 1.7k Sep 22, 2022
­čöî Simple library to manipulate HTTP requests/responses and capture network logs made by the browser using selenium tests without using any proxies

Simple library to manipulate HTTP requests and responses, capture the network logs made by the browser using selenium tests without using any proxies

Sudharsan Selvaraj 28 Dec 10, 2021
­čč¬ DeepfakeHTTP is a web server that uses HTTP dumps as a source for responses.

DeepfakeHTTP ÔÇô Your 100% static dynamic backend DeepfakeHTTP is a web server that uses HTTP dumps as a source for responses. What are people using it

null 422 Sep 28, 2022
Lightweight analysis tool for detecting mutability in Java classes

What is Mutability Detector? Mutability Detector is designed to analyse Java classes and report on whether instances of a given class are immutable. I

Mutability Detector 232 Jul 7, 2022
ShotDroid is a pentesting tool for android.

ShotDroid is a pentesting tool for android. There are 3 tools that have their respective functions, Get files from Android directory, internal and external storage, Android Keylogger + Reverse Shell and Take a webcam shot of the face from the front camera of the phone and PC.

null 157 Sep 28, 2022
simple web3j Demo to be continue´╝îuse web3j Brainless Trading,tool for arbitrage automatic trading, copying other transfer´╝îtracking agency addresses, setting profit points, setting prices, grabbing blocks

simple web3j Demo to be continue´╝îuse web3j Brainless Trading,tool for arbitrage automatic trading, copying other transfer´╝îtracking agency addresses, setting profit points, setting prices, grabbing blocks

Nate River 240 Sep 27, 2022
High-level contextual steps in your tests for any reporting tool

Xteps High-level contextual steps in your tests for any reporting tool. License Maven Central Javadoc Xteps Xteps Allure Xteps ReportPortal How to use

Evgenii Plugatar 3 Mar 27, 2022
WireMock - A tool for mocking HTTP services

WireMock only uses log4j in its test dependencies. Neither the thin nor standalone JAR depends on or embeds log4j, so you can continue to use WireMock 2.32.0 without any risk of exposue to the recently discovered vulnerability.

null 5.2k Sep 30, 2022
MockServer enables easy mocking of any system you integrate with via HTTP or HTTPS with clients written in Java, JavaScript and Rub

MockServer enables easy mocking of any system you integrate with via HTTP or HTTPS with clients written in Java, JavaScript and Ruby. MockServer also includes a proxy that introspects all proxied traffic including encrypted SSL traffic and supports Port Forwarding, Web Proxying (i.e. HTTP proxy), HTTPS Tunneling Proxying (using HTTP CONNECT) and SOCKS Proxying (i.e. dynamic port forwarding).

Mock-Server 3.9k Oct 2, 2022
httpx - CLI to test HTTP/gRPC/RSocket/Kafka... services by HTTP DSL

httpx: CLI for run http file httpx is a CLI to execute requests from JetBrains Http File. Request types supported by httpx HTTP REST PUB/SUB - Apache

servicex-sh 89 Sep 26, 2022
Eclipse Jetty® - Web Container & Clients - supports HTTP/2, HTTP/1.1, HTTP/1.0, websocket, servlets, and more

Eclipse Jetty Canonical Repository This is the canonical repository for the Jetty project, feel free to fork and contribute now! Submitting a patch or

Eclipse Foundation 3.4k Oct 5, 2022
Most popular Mocking framework for unit tests written in Java

Most popular mocking framework for Java Current version is 3.x Still on Mockito 1.x? See what's new in Mockito 2! Mockito 3 does not introduce any bre

mockito 13.3k Oct 3, 2022
Advanced Java library for integration testing, mocking, faking, and code coverage

Codebase for JMockit 1.x releases - Documentation - Release notes How to build the project: use JDK 1.8 or newer use Maven 3.6.0 or newer; the followi

The JMockit Testing Toolkit 433 Sep 11, 2022