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.

Issues
  • 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 130
  • 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
  • Android support

    Android support

    Any plans for Android support? I tried it and it didn't work out of the box.

    opened by yogurtearl 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
  • Adding Remove Stub API

    Adding Remove Stub API

    I am adding a new API in stand alone mode to be able to remove a stub mapping - you can contact me

    [email protected] / @akshaydeodhar

    opened by planetakshay 30
  • 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.

    Feature request 
    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
  • Consider downgrading to Jetty 9.2

    Consider downgrading to Jetty 9.2

    Jetty 9.3 is known to cause problems with Jersey and it requires Java 8, which causes many problems with projects depending on WireMock

    opened by jkubrynski 23
  • Document running Wiremock without HTTP Server

    Document running Wiremock without HTTP Server

    I've recently discovered and blogged about how to run Wiremock without an HTTP server.

    This is something that is on the autocomplete when searching google for wiremock without, so I feel this is something that's quite likely to be wanted by users.

    At the very least, I've found it to be a requirement to put Wiremock into a serverless function, and found this solution to work really nicely.

    I'd be happy to raise a PR to add this to the documentation, as well as adding a regression test to the codebase to ensure that this functionality is still available in the future.

    opened by jamietanna 0
  • 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.

    opened by andy-cross 2
  • Resolve sonatype issues

    Resolve sonatype issues

    commons-io upgraded netty-all upgraded log4j upgraded to log4j2

    Also, would not build due to node-sass 4.12.0 no longer found at location. Upgraded to 4.14.1 to resolve the build issue.

    opened by tacotown 2
  • Logging redesign

    Logging redesign

    WireMock's logging has become unfit for purpose and needs a major overhaul.

    Specific problems include:

    • Lack of control over what gets logged.
    • Lack of distinction between system (Java class level), requests/serve events and debug info from the matching system.
    • Very little control over format - in particular use with log aggregators is difficult.
    • No control over log destination(s) when running standalone - everything goes to stdout.
    • Standalone JAR includes its own logger implementation, which is OK when running it as a standalone process, but not so good it's a dependency.
    • Jetty logging makes use of system variables (see #1420)

    See also: #912 #720 #776 #1018 #1126

    Feature request 
    opened by tomakehurst 0
  • Bump jsonassert from 1.2.3 to 1.5.0

    Bump jsonassert from 1.2.3 to 1.5.0

    Bumps jsonassert from 1.2.3 to 1.5.0.

    Release notes

    Sourced from jsonassert's releases.

    JSONassert 1.5.0

    Version 1.5.0 - 3/19/2017

    • JSONassert now supports user-supplied error messages (thanks [email protected]!)
    • Some refactoring / code health cleanup (thanks [email protected]!)
    • License headers on individual files
    • Java 8 friendly javadocs

    JSONAssert 1.4.0

    • Change the implementation for org.json to one with a more open license
    • Fix null pointer exception (issue #48)
    • Support wildcards in Customization.path

    JSONAssert 1.3.0

    • Fix & improve ArrayValueMatcher JavaDoc (dmackinder)
    • Fix final JavaDoc example and add new example showing how to verify every array element using a custom comparator
    • Fix URL in pom.xml (aukevanleeuwen)
    • Update JSONCompareResult.java adding 2 new lists for missing and unexpected fileds (riccorazza)
    • Includes missing imports in test class (javierseixas)
    Changelog

    Sourced from jsonassert's changelog.

    Version 1.5.0 - 3/19/2017

    • JSONassert now supports user-supplied error messages (thanks [email protected]!)
    • Some refactoring / code health cleanup (thanks [email protected]!)
    • License headers on individual files
    • Java 8 friendly javadocs

    Version 1.4.0 - 10/30/2016

    • Change the implementation for org.json to one with a more open license
    • Fix null pointer exception (issue #48)
    • Support wildcards in Customization.path

    Version 1.3.0 - 12/16/2015

    • Fix & improve ArrayValueMatcher JavaDoc (thanks dmackinder!) Fix final JavaDoc example and add new example showing how to verify every array element using a custom comparator
    • Fix URL in pom.xml (aukevanleeuwen)
    • Update JSONCompareResult.java adding 2 new lists for missing and unexpected fileds (thanks riccorazza!)
    • Includes missing imports in test class (thanks javierseixas!)
    Commits
    • a47fe83 [maven-release-plugin] prepare release jsonassert-1.5.0
    • 21d62b6 Revert "[maven-release-plugin] prepare release jsonassert-1.5.0"
    • 2ddd936 [maven-release-plugin] prepare for next development iteration
    • 055e9f8 [maven-release-plugin] prepare release jsonassert-1.5.0
    • 339479a Revert "[maven-release-plugin] prepare release jsonassert-1.5.0"
    • 9613bbe [maven-release-plugin] prepare release jsonassert-1.5.0
    • 21cfa8b Reverting to pre-release
    • e31d4d9 [maven-release-plugin] prepare for next development iteration
    • f75cf9b [maven-release-plugin] prepare release jsonassert-1.5.0
    • 7d22b48 Fix compiler error due to param rename.
    • 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
  • Bump nokogiri from 1.10.7 to 1.11.3 in /docs-v2

    Bump nokogiri from 1.10.7 to 1.11.3 in /docs-v2

    Bumps nokogiri from 1.10.7 to 1.11.3.

    Release notes

    Sourced from nokogiri's releases.

    1.11.3 / 2021-04-07

    Fixed

    • [CRuby] Passing non-Node objects to Document#root= now raises an ArgumentError exception. Previously this likely segfaulted. [#1900]
    • [JRuby] Passing non-Node objects to Document#root= now raises an ArgumentError exception. Previously this raised a TypeError exception.
    • [CRuby] arm64/aarch64 systems (like Apple's M1) can now compile libxml2 and libxslt from source (though we continue to strongly advise users to install the native gems for the best possible experience)

    1.11.2 / 2021-03-11

    Fixed

    • [CRuby] NodeSet may now safely contain Node objects from multiple documents. Previously the GC lifecycle of the parent Document objects could lead to nodes being GCed while still in scope. [#1952]
    • [CRuby] Patch libxml2 to avoid "huge input lookup" errors on large CDATA elements. (See upstream GNOME/libxml2#200 and GNOME/libxml2!100.) [#2132].
    • [CRuby+Windows] Enable Nokogumbo (and other downstream gems) to compile and link against nokogiri.so by including LDFLAGS in Nokogiri::VERSION_INFO. [#2167]
    • [CRuby] {XML,HTML}::Document.parse now invokes #initialize exactly once. Previously #initialize was invoked twice on each object.
    • [JRuby] {XML,HTML}::Document.parse now invokes #initialize exactly once. Previously #initialize was not called, which was a problem for subclassing such as done by Loofah.

    Improved

    • Reduce the number of object allocations needed when parsing an HTML::DocumentFragment. [#2087] (Thanks, @​ashmaroli!)
    • [JRuby] Update the algorithm used to calculate Node#line to be wrong less-often. The underlying parser, Xerces, does not track line numbers, and so we've always used a hacky solution for this method. [#1223, #2177]
    • Introduce --enable-system-libraries and --disable-system-libraries flags to extconf.rb. These flags provide the same functionality as --use-system-libraries and the NOKOGIRI_USE_SYSTEM_LIBRARIES environment variable, but are more idiomatic. [#2193] (Thanks, @​eregon!)
    • [TruffleRuby] --disable-static is now the default on TruffleRuby when the packaged libraries are used. This is more flexible and compiles faster. (Note, though, that the default on TR is still to use system libraries.) [#2191, #2193] (Thanks, @​eregon!)

    Changed

    • Nokogiri::XML::Path is now a Module (previously it has been a Class). It has been acting solely as a Module since v1.0.0. See 8461c74.

    v1.11.1 / 2021-01-06

    Fixed

    • [CRuby] If libxml-ruby is loaded before nokogiri, the SAX and Push parsers no longer call libxml-ruby's handlers. Instead, they defensively override the libxml2 global handler before parsing. [#2168]

    SHA-256 Checksums of published gems

    a41091292992cb99be1b53927e1de4abe5912742ded956b0ba3383ce4f29711c  nokogiri-1.11.1-arm64-darwin.gem
    d44fccb8475394eb71f29dfa7bb3ac32ee50795972c4557ffe54122ce486479d  nokogiri-1.11.1-java.gem
    f760285e3db732ee0d6e06370f89407f656d5181a55329271760e82658b4c3fc  nokogiri-1.11.1-x64-mingw32.gem
    dd48343bc4628936d371ba7256c4f74513b6fa642e553ad7401ce0d9b8d26e1f  nokogiri-1.11.1-x86-linux.gem
    7f49138821d714fe2c5d040dda4af24199ae207960bf6aad4a61483f896bb046  nokogiri-1.11.1-x86-mingw32.gem
    5c26111f7f26831508cc5234e273afd93f43fbbfd0dcae5394490038b88d28e7  nokogiri-1.11.1-x86_64-darwin.gem
    c3617c0680af1dd9fda5c0fd7d72a0da68b422c0c0b4cebcd7c45ff5082ea6d2  nokogiri-1.11.1-x86_64-linux.gem
    </tr></table> 
    

    ... (truncated)

    Changelog

    Sourced from nokogiri's changelog.

    1.11.3 / 2021-04-07

    Fixed

    • [CRuby] Passing non-Node objects to Document#root= now raises an ArgumentError exception. Previously this likely segfaulted. [#1900]
    • [JRuby] Passing non-Node objects to Document#root= now raises an ArgumentError exception. Previously this raised a TypeError exception.
    • [CRuby] arm64/aarch64 systems (like Apple's M1) can now compile libxml2 and libxslt from source (though we continue to strongly advise users to install the native gems for the best possible experience)

    1.11.2 / 2021-03-11

    Fixed

    • [CRuby] NodeSet may now safely contain Node objects from multiple documents. Previously the GC lifecycle of the parent Document objects could lead to nodes being GCed while still in scope. [#1952]
    • [CRuby] Patch libxml2 to avoid "huge input lookup" errors on large CDATA elements. (See upstream GNOME/libxml2#200 and GNOME/libxml2!100.) [#2132].
    • [CRuby+Windows] Enable Nokogumbo (and other downstream gems) to compile and link against nokogiri.so by including LDFLAGS in Nokogiri::VERSION_INFO. [#2167]
    • [CRuby] {XML,HTML}::Document.parse now invokes #initialize exactly once. Previously #initialize was invoked twice on each object.
    • [JRuby] {XML,HTML}::Document.parse now invokes #initialize exactly once. Previously #initialize was not called, which was a problem for subclassing such as done by Loofah.

    Improved

    • Reduce the number of object allocations needed when parsing an HTML::DocumentFragment. [#2087] (Thanks, @​ashmaroli!)
    • [JRuby] Update the algorithm used to calculate Node#line to be wrong less-often. The underlying parser, Xerces, does not track line numbers, and so we've always used a hacky solution for this method. [#1223, #2177]
    • Introduce --enable-system-libraries and --disable-system-libraries flags to extconf.rb. These flags provide the same functionality as --use-system-libraries and the NOKOGIRI_USE_SYSTEM_LIBRARIES environment variable, but are more idiomatic. [#2193] (Thanks, @​eregon!)
    • [TruffleRuby] --disable-static is now the default on TruffleRuby when the packaged libraries are used. This is more flexible and compiles faster. (Note, though, that the default on TR is still to use system libraries.) [#2191, #2193] (Thanks, @​eregon!)

    Changed

    • Nokogiri::XML::Path is now a Module (previously it has been a Class). It has been acting solely as a Module since v1.0.0. See 8461c74.

    1.11.1 / 2021-01-06

    Fixed

    • [CRuby] If libxml-ruby is loaded before nokogiri, the SAX and Push parsers no longer call libxml-ruby's handlers. Instead, they defensively override the libxml2 global handler before parsing. [#2168]

    1.11.0 / 2021-01-03

    Notes

    Faster, more reliable installation: Native Gems for Linux and OSX/Darwin

    "Native gems" contain pre-compiled libraries for a specific machine architecture. On supported platforms, this removes the need for compiling the C extension and the packaged libraries. This results in much faster installation and more reliable installation, which as you probably know are the biggest headaches for Nokogiri users.

    We've been shipping native Windows gems since 2009, but starting in v1.11.0 we are also shipping native gems for these platforms:

    ... (truncated)

    Commits
    • d244fb8 version bump to v1.11.3
    • 5562eb7 Merge pull request #2215 from sparklemotion/flavorjones-valgrind-test-helpers
    • 72d96fe test: consolidate jruby version info tests
    • d33b021 test: cleanup
    • c75ce9b test: introduce helpers for skips and for a valgrind block
    • cb36a56 ci: make some slow tests run only under NOKOGIRI_GC
    • beb77f5 Merge pull request #2214 from sparklemotion/flavorjones-allow-arm64-compilation
    • 8380a6d fix: update automake files to allow arm64 to compile package libs
    • acfd92c Revert "fix: update automake files to allow arm64 to compile package libs"
    • 65c0ba1 fix: update automake files to allow arm64 to compile package libs
    • 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) You can disable automated security fix PRs for this repo from the Security Alerts page.
    dependencies ruby 
    opened by dependabot[bot] 0
  • Bump jmock-junit4 from 2.5.1 to 2.12.0

    Bump jmock-junit4 from 2.5.1 to 2.12.0

    Bumps jmock-junit4 from 2.5.1 to 2.12.0.

    Release notes

    Sourced from jmock-junit4's releases.

    2.12.0 Bug fixes and upgrades

    No release notes provided.

    2.11.0 DeterministicScheduler changes

    Include #124

    2.10.0 Java 11 Support

    tl;dr Support Java 11 Change default CGLIB ClassImposteriser with ByteBuddy ClassImposteriser supporting Java11

    Many developers don't use interfaces anymore so the ClassImposteriser is critical. We could even consider moving/promoting the ByteBuddy ClassImposteriser into jmock (core).

    v2.9.0

    No release notes provided.

    v2.8.4

    No release notes provided.

    v2.8.2

    Upgrade cglib and asm for the ClassImposteriser to support Java8.

    Commits
    • 488bfea Version 2.12.0
    • b1792c9 Reports can't read new Java 9 bytecode constants
    • 9941729 Apply dependency upgrades
    • 05045a7 Display upgrades inline, because I rarely create/read the site report
    • 706db90 Add issue #127 test
    • c98e818 These fixes don't actually require JDK9
    • 2e5557d Allow failures with early access JDKs
    • 1262a70 Target 2.12.0 as there have been test case moves
    • 02d9bdc Upgrade travis JDK yaml
    • 3993fb8 Merge remote-tracking branch 'upstream/master'
    • 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 
    opened by dependabot[bot] 0
  • Content type mime lowercase

    Content type mime lowercase

    When adding a mapping with header Content-Type I see there's a mismatch in casing between what is in the mapping and what wiremock sends as response.

    For example if this is my mapping:

    {
        "request": {
            "method": "GET",
            "url": "/api/mytest"
        },
        "response": {
            "status": 200,
            "body": "{\"test\":\"value\"}",
            "headers": {
                        "Content-Type": "APPLICATION/JSON"
             }
        }
    }
    

    When I call wiremock against this mapping I get application/json as my Content type header value not APPLICATION/JSON. If I change it to some other invalid mime type like RANDOM/RANDOM thats what I get back. but I believe any valid matched mime is automatically converted to lowercase. I'm looking for this specifically since it's possible for a call I make from my app to send APPLICATION/JSON and I want to be sure my app is able to handle it.

    Bug 
    opened by ganeshramc 2
  • Bump jmock from 2.5.1 to 2.12.0

    Bump jmock from 2.5.1 to 2.12.0

    Bumps jmock from 2.5.1 to 2.12.0.

    Release notes

    Sourced from jmock's releases.

    2.12.0 Bug fixes and upgrades

    No release notes provided.

    2.11.0 DeterministicScheduler changes

    Include #124

    2.10.0 Java 11 Support

    tl;dr Support Java 11 Change default CGLIB ClassImposteriser with ByteBuddy ClassImposteriser supporting Java11

    Many developers don't use interfaces anymore so the ClassImposteriser is critical. We could even consider moving/promoting the ByteBuddy ClassImposteriser into jmock (core).

    v2.9.0

    No release notes provided.

    v2.8.4

    No release notes provided.

    v2.8.2

    Upgrade cglib and asm for the ClassImposteriser to support Java8.

    Commits
    • 488bfea Version 2.12.0
    • b1792c9 Reports can't read new Java 9 bytecode constants
    • 9941729 Apply dependency upgrades
    • 05045a7 Display upgrades inline, because I rarely create/read the site report
    • 706db90 Add issue #127 test
    • c98e818 These fixes don't actually require JDK9
    • 2e5557d Allow failures with early access JDKs
    • 1262a70 Target 2.12.0 as there have been test case moves
    • 02d9bdc Upgrade travis JDK yaml
    • 3993fb8 Merge remote-tracking branch 'upstream/master'
    • 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 
    opened by dependabot[bot] 0
  • Swagger UI blank page with errors

    Swagger UI blank page with errors

    After upgrading to wiremock-jre8-standalone-2.27.2.jar, everything seems to work, except navigating to __admin/swagger-ui give the message "Error fetching resource list ... Please wait" and freezes. Further attempts to load the Swagger page give a blank page.

    I also tried the same with wiremock-jre8-standalone-2.26.3.jar with the same issue.

    When I downgrade to wiremock-standalone-2.7.1.jar, everything works fine. I have not tried any other versions in between.

    I am setting the following flags on the standalone when starting:

    --enable-browser-proxying --port --record-mappings --verbose --root-dir

    I see the following errors when I inspect the page:

    swagger-ui.css:1 Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH swagger-ui-standalone-preset.js:1 Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH swagger-ui-bundle.js:1 Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH (index):77 Uncaught ReferenceError: SwaggerUIBundle is not defined at window.onload ((index):77) window.onload @ (index):77 load (async) (anonymous) @ (index):73

    I am running the standalone jar on 3.10.0-1160.11.1.el7.x86_64 GNU/Linux. I have tried both Chrome 89.0.4389.114 (Official Build) (x86_64) and Safari Version 14.0.3 (16610.4.3.1.7) browsers.

    Bug 
    opened by DanielPMish 5
Releases(1.52-beta)
  • 1.52-beta(Oct 24, 2014)

Owner
Tom Akehurst
Tom Akehurst
PowerMock is a Java framework that allows you to unit test code normally regarded as untestable.

Writing unit tests can be hard and sometimes good design has to be sacrificed for the sole purpose of testability. Often testability corresponds to go

PowerMock 3.4k Mar 15, 2021
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 11.6k Mar 13, 2021
A tool for mocking HTTP services

WireMock - a web service test double for all occasions Key Features HTTP response stubbing, matchable on URL, header and body content patterns Request

Tom Akehurst 4.4k Apr 22, 2021
Java binding for Hoverfly

Hoverfly Java - Easy Creation of Stub Http Servers for Testing A Java native language binding for Hoverfly, a Go proxy which allows you to simulate ht

null 130 Feb 7, 2021
Test Automation Made Simple

Karate Test Automation Made Simple. Karate is the only open-source tool to combine API test-automation, mocks, performance-testing and even UI automat

Intuit 4.5k Mar 13, 2021
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 37 Mar 23, 2021
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 5.2k Mar 13, 2021
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 5.2k Mar 15, 2021
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 218 Mar 1, 2021
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 95 Feb 16, 2021
Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container.

Testcontainers Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium we

null 4.7k Mar 13, 2021
The Enterprise-ready testing and specification framework.

Spock Framework Spock is a BDD-style developer testing and specification framework for Java and Groovy applications. To learn more about Spock, visit

Spock Framework 2.8k Mar 14, 2021
FitNesse -- The Acceptance Test Wiki

FitNesse Welcome to FitNesse, the fully integrated stand-alone acceptance testing framework and wiki. To get started, check out http://fitnesse.org! Q

Robert C. Martin 1.6k Mar 14, 2021
Layout and functional testing framework for websites

Galen Framework master: Galen is an open-source tool for testing layout and responsive design of web applications. It is also a powerfull functional t

Galen Framework 1.4k Mar 5, 2021