Debugging Issues

MockServer supports the following features to simplify debugging

• Configurable log level
• Clear and simple log messages for all actions
• Clear failure messages when verifying requests (that support "show difference" in IntelliJ)
• Ability to dump all configured expectations to the log

In addition MockServer has simple and straight forward code that can be easily debugged manually when the logs don't provide enough information to determine why something is behaving as expected.

Logging

All interactions with the MockServer are logged including setting up expectations, matching expectations, clearing expectations and verifying requests. The log can be particularly helpful when trying to debug why a test is failing or expectations are not being matched.

The following information is logged:

• WARN - exceptions, errors and expectation dump when mockServerClient.dumpToLog() is called
• INFO - all interactions with the MockServer including setting up expectations, matching expectations, clearing expectations and verifying requests
• TRACE - all matcher results, including when specific matchers fail (such as HeaderMatcher)

The TRACE level logging results in a lot of verbose logging but can be very helpful to debug why a complex matcher (such as the JSON Schema matcher) is not matching.

When MockServer is run from the command line, Maven plugin, npm module or Grunt plugin the log is written to a file called mockserver.log in the current working directory where the MockServer is running.

Logging with JUnit @Rule or API

If the MockSever is being launched using the JUnit @Rule or programmatically via an API then a custom logback configuration file to override the default MockServer or MockServer Proxy logging settings. An example logback configuration file is available in github.

A custom logback configuration file can be specified using the logback.configurationFile system property with an absolute or relative file path or a classpath, as follows: -Dlogback.configurationFile=example_logback.xml

A custom logback configuration file will also be automatically picked up if it is called logback.xml and is in the root of the classpath, however, the jar-with-dependencies already contains a logback.xml file, so to override this, the overriding logback.xml file must be higher (i.e. earlier) in the classpath.

Logging with Command Line

When running MockServer directly from the command line the system property mockserver.logLevel can be used to set the log level, as follows:

java -Dmockserver.logLevel=INFO -jar ~/Downloads/mockserver-netty-4.0.0-jar-with-dependencies.jar -serverPort 1080 -proxyPort 1090

It is also possible to specify a custom logback configuration file to override the default MockServer or MockServer Proxy logging settings. An example logback configuration file is available in github.

A custom logback configuration file can be specified using the logback.configurationFile system property with an absolute or relative file path or a classpath, as follows:

java -Droot.logLevel=WARN -Dmockserver.logLevel=INFO -Dlogback.configurationFile=example_logback.xml -jar ~/Downloads/mockserver-netty-4.0.0-jar-with-dependencies.jar -serverPort 1080 -proxyPort 1090

A custom logback configuration file will also be automatically picked up if it is called logback.xml and is in the root of the classpath, however, the jar-with-dependencies already contains a logback.xml file, so to override this, the overriding logback.xml file must be higher (i.e. earlier) in the classpath.

Logging with Maven Plugin

The mockserver-maven-plugin provides a logLevel settings that can be used to define the log level for all MockServer and MockServer Proxy classes, as follows:

 <plugin>
     <groupId>org.mock-server</groupId>
     <artifactId>mockserver-maven-plugin</artifactId>
     <version>4.0.0</version>
     <configuration>
        <serverPort>1080</serverPort>
        <proxyPort>1090</proxyPort>
        <logLevel>DEBUG</logLevel>
     </configuration>
     <executions>
         <execution>
             <id>process-test-classes</id>
             <phase>process-test-classes</phase>
             <goals>
                 <goal>runForked</goal>
             </goals>
         </execution>
         <execution>
             <id>verify</id>
             <phase>verify</phase>
             <goals>
                 <goal>stopForked</goal>
             </goals>
         </execution>
     </executions>
 </plugin>

Logging with npm module or Grunt plugin

When running MockServer using the mockserver-node Grunt plugin and Node.js (npm) module the verbose option can be used to enable INFO level logging and the trace option can be used to enable TRACE level logging. In addition the --verbose command line flag can be used for Grunt builds to enable the mockserver-node verbose option dynamically.

Disabling Logging

To disable logging the following options can be used:

• -Dmockserver.logLevel=OFF - to disable logging from the MockServer and MockServer Proxy classes
• -Droot.logLevel=OFF - to disable all logging from all other classes (i.e. all none MockServer and MockServer Proxy classes)

If logging is disabled then no log file will be created. This is because the log files are only created when the first item is written to the log file.

Dumping Expectations To Log

To simplify debugging MockServer expectations can be dumped to the log at WARN level using pretty-printed JSON.

To dump all expectations to the log use dumpToLog as follows:

Java

new MockServerClient("localhost", 1080).dumpToLog()

JavaScript

mockServerClient("localhost", 1080).dumpToLogs();

Ruby

client = MockServerClient.new('localhost', 1080)
client.dump_log()

To dump only specific expectations to the log use dumpToLog as follows:

Java

new MockServerClient("localhost", 1080).dumpToLog(
        request()
                .withMethod("GET")
                .withPath("/somePath")
);

JavaScript

mockServerClient("localhost", 1080).dumpToLogs('/somePath');

Ruby

client = MockServerClient.new('localhost', 1080)
client.dump_log(request(:GET, '/somePath'))

Debugging Java Code

To further understand why an exception is not being matched it is possible to debug the MockServer java code, in the following classes:

• org.mockserver.mockserver.MockServerHandler - main entry point for handling requests in for all versions of MockServer except the deployable WAR
• org.mockserver.server.MockServerServlet - main entry point for handling requests in the deployable WAR
• org.mockserver.matchers.HttpRequestMatcher - main class that orchestrates request matching
• org.mockserver.mock.MockServerMatcher - main class that orchestrates expectation, including matching, ttl, times and returning correct action

Debugging JUnit @Rule or API

Debugging when using the JUnit @Rule or API should be as simple as running your test in debug.

Debugging Command Line

Debugging a remote JVM (i.e. when running MockServer from the command line) typically requires providing the -agentlib:jdwp command line switch, as follows:

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005 -jar ~/Downloads/mockserver-netty-4.0.0-jar-with-dependencies.jar -serverPort 1080 -proxyPort 1090

Debugging Maven Plugin

Maven can be debugged using mvnDebug which using a debug port of 8000, as follows:

mvnDebug test

mvnDebug runs the JVM using the following additional settings: -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000

If you are using the surefire plugin to run your tests you can debug your tests using the surefire plugin debug options, as follows:

mvn -Dmaven.surefire.debug test

If you are using the failsafe plugin to run your tests you can debug your tests using the failsafe plugin debug options, as follows:

mvn -Dmaven.failsafe.debug verify

Debugging npm module or Grunt plugin

To debug the npm module or Grunt plugin you need to provide the javaDebugPort option. This option will enable the following command line switch '-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=' + options.javaDebugPort.

For example debug node module, as follows:

var mockserver = require('mockserver-node');
mockserver.start_mockserver({
                serverPort: 1080,
                proxyPort: 1090,
                javaDebugPort: 5005
            });

// do something

mockserver.stop_mockserver();

For example debug Grunt plugin, as follows:

grunt.initConfig({
    start_mockserver: {
        start: {
            options: {
                serverPort: 1080,
                proxyPort: 1090,
                javaDebugPort: 5005
            }
        }
    },
    stop_mockserver: {
        stop: {

        }
    }
});

grunt.loadNpmTasks('mockserver-node');