Rather than requiring an output directory to be explcitly configured,
a default is now automatically configured based on the build tool
that's being used. When using Gradle, snippets will be generated in
build/generated-snippets. When using Maven, snippets will be
generated in target/generated-snippets.
See gh-297
Previously, spring-restdocs-core had a dependency on spring-webmvc
however it only used classes from spring-web. This commit moves
the spring-webmvc dependency from spring-restdocs-core to
spring-restdocs-mockmvc where it's needed. It's now in the runtime
scope (rather than compile) as it's not needed at compile time but
is needed at runtime by the MockMvc support in spring-test.
Closes gh-273
Previously, if a MockMvc request was made with parameters and body
content, the parameters were omitted from the resulting curl, HTTPie
and HTTP request snippets.
This commit updates the affected snippets to ensure that the
parameters are included. The user-provided content is interpreted
as indicating that the parameters should be sent in the query string
rather than as form-encoded content.
Closes gh-239
Previously, OperationRequestFactory would add a Host header if one did
not already exist in the request’s headers, however it did not include
the port. This meant that when the request was being made to a
non-standard port (a port other than 80 for an HTTP request and 443 for
an HTTPS request) the Host header was incorrect.
This commit updates OperationRequestFactory to check the URI for a port
and, if it has one, include it in the Host header.
UriModifyingOperationPreprocessor has also been updated to correctly
include the port in the Host header.
Closes gh-269
Previously, if alwaysDo was used and the user wanted to generate
one or more additional snippets when calling perform a separate call
to `snippets` was made prior to calling `perform`. This had two
problems:
- it required the result handler to be stateful (see gh-243)
- it wasn't clear that the additional snippets would be produced when
a subsequent call to perform was made
This commit introduces a new API that allows the additional snippets
to be specified within the MockMvc call. The old API has been
deprecated and will be removed in 2.0.
Closes gh-249
Previously, a LinkDescriptor had to be created with both a rel and a
description. If a description was not provided a failure would occur.
This commit relaxes the above-described restriction by allowing a
link's title to be used as its default description. If a descriptor
has a description, it will always be used irrespective of whether or
not the link has a title. If the descriptor does not have a
description and the link does have a title, the link's title will be
used. If the descriptor does not have a description and the link does
not have a title a failure will occur.
Closes gh-105
This commit polishes the HTTPie request snippet contribution made in
b26d8c0. It makes the following significant changes:
- Applies project’s coding conventions for formatting and the like
- Moves to a composition-based approach for sharing functionality
between the curl and HTTPie snippets by replacing AbstractCliSnippet
with CliOperationRequest.
- Introduces a single package for CLI command snippets, thereby allowing
more code to be package-private.
See gh-207
In 1.0, the reliance on JUnit was more widespread than it should have
been. It should have been isolated to the JUnit TestRule implementation,
RestDocumentation. Unfortunately, RestDocumentation was also an argument
to MockMvcRestDocumentation.documentationConfiguration which made it
impossible to use Spring REST Docs without having JUnit on the
classpath.
This commit introduces JUnitRestDocumentation and
ManualRestDocumentation. The format is a direct replacement for
RestDocumentation which has been reworked to delegate to
JUnitRestDocumentation. The latter allows manual management of the
RestDocumentationContext, primarily for use with TestNG.
A new interface, RestDocumentationContextProvider, has been introduced.
It is implemented by RestDocumentation, JUnitRestDocumentation and
ManualRestDocumentation.
MockMvcRestDocumentation.documentationConfiguration has been overridden
to also accept a RestDocumentationContextProvider. The method that
accepts a RestDocumentation has been deprecated, as has
RestDocumentation itself.
The documentation has been updated to encourage the use of
JUnitRestDocumentation and a sample illustrating the use of Spring REST
Docs with TestNG has been added.
Closes gh-171
Previously, logic for creating an Operation, determining the snippets
to call, and calling them was duplicated in both the MockMvc and
REST Assured modules. This commit introduces a new core class,
RestDocumentationHandler, that now does the bulk of the work in a
reusable manner. The MockMvc and REST Assured modules have been
updated to delegate to RestDocumentationHandler.
Closes gh-194
This commit introduces support for generating snippets formatted
using Markdown. Asciidoctor remains the default.
A new SnippetFormat abstraction has been introduced with Asciidoctor
and Markdown implementations provided out of the box.
Markdown-formatted templates are also provided for all of the default
snippets.
Please refer to the updated reference documentation for further
details.
Closes gh-150
Closes gh-19
This commit adds a new module, spring-restdocs-restassured, that
can be used to generate documentation snippets when testing a service
with REST Assured.
Please refer to the updated reference documentation for details.
Thanks to Johan Haleby for making a change to REST Assured so that
path parameters could be documented.
Closes gh-102
Previously, it was necessary to document every payload field, link,
path parameter, or request. If an item was not documented a failure
would occur. This has proven to be too restrictive for some use cases,
for example splitting up the documentation of a payload’s fields. While
it was possible to use a preprocessor to modify the operation prior to
documentation to remove the items that should not be documented, this
was more difficult than it needed to be.
This commit adds support for marking a descriptor as ignored. Ignored
descriptors count when checking that everything has been documented but
do not actually appear in the generated documentation.
Closes gh-143
Previously, if a request had no content and it was a POST or a PUT
request, the curl request snippet would use the request's parameters
as application/x-www-form-urlencoded data sent using the -d option.
This resulted in the wrong snippet being produced if those parameters
had actually come from the request's query string.
This commit enhances CurlRequestSnippet so that, when it's using the
request's parameter's to create its content, it only includes
parameters that are not specified in the query string. With these
changes in place, this MockMvc request:
post("/?foo=bar").param("foo", "bar").param("a", "alpha")
Will produce a curl snippet with the following command:
$ curl 'http://localhost:8080/?foo=bar' -i -X POST -d 'a=alpha'
foo=bar only appears in the command's query string, despite also
being a general request parameter, and a=alpha only appears in the
request's data.
Closes gh-139
Previously, the Host header was treated specially in the HTTP request
snippet. If no Host header was specified, one would always be added
prior to producing the snippet. This ensured that the snippet was
valid (an HTTP 1.1 request must include a Host header), but came at
the cost of some confusion about why a preprocessor could not remove
it.
This commit updates the special treatment of the Host header so that
it's now performed in a central location so that all of the snippets
can benefit from a Host header being added if one isn't provided.
The handling of the Content-Length header has also been reworked so
that it's performed in the same location. The curl request snippet
has been updated so that it doesn't include setting the Host header
on the command line; it's unnecessary as curl will automatically
include a Host header in the request. The documentation of the
Host header's special treatment (made in 2fc0420) that noted that it
was unaffected by preprocessing has been reverted.
Closes gh-134
Previously, some MockMvc-specific logic would add a Content-Length
header to every request that had content. This led to the curl request
snippet containing a -H option for the Content-Length header. This is
unnecessary as curl will automatically generate a Content-Length
header based on the data that's being sent to the server. A secondary
problem was the inconsistent automatic addition of a Content-Length
header; the header was not automatically added to responses.
This commit remove the MockMvc-specific logic in favour of some new
logic in the core project to automatically add a Content-Length header
to both requests and responses. The curl request snippet has been
updated to supress the header in favour of curl's automatic
generation.
Closes gh-111
This commit configures Checkstyle and updates the build to comply with
that configuration. The Eclipse JDT metadata has also been updated
so that the output of Eclipse’s code formatting and clean-up is
compliant with Checkstyle.
The use of the latest version (6.10.1) of Checkstyle has required an
upgrade to Gradle 2.7. Gradle hardcode’s the name of the Checkstyle’s
main class which has changed between version 5 (Gradle’s default) and
version 6.
Closes gh-119
Following the reworking of the API, it was no longer possible to
apply preprocessing to every test and to still customize the snippets
used by that test.
This commit adds a new snippets() method to
RestDocumentationResultHandler that allows additional snippets to be
configured once the result handler has been created. The documentation
has been updated to describe how to apply preprocessing to every
test and Spring HATEOAS sample has been updated to illustrate the
approach.
Closes gh-88
Windows uses \r\n for line endings whereas Unix-like platforms us
\n. This causes the content length of a pretty-printed response to
be longer on Windows.
This commit splits Spring REST Docs into two projects –
spring-restdocs-core and spring-restdocs-mockmvc.
spring-restdocs-core contains the vast majority of the code but does not
depend on a specific test framework other than JUnit. The use of a
Spring Test TestExecutionListener has been replaced with a JUnit test
rule. The rule is declared once per test class and configured with
the output directory to which the generated snippets should be written.
This simplifies the implementation as thread local storage is no longer
required to transfer information about the test that’s running into
Spring REST Docs. Instead, this transfer is now handled by the new test
rule. It has also simplified the configuration as it’s no longer
necessary for users to provide a system property that configures the
output directory.
spring-restdocs-mockmvc contains code that’s specific to using Spring
REST Docs with Spring MVC Test’s MockMvc. This is currently the only
testing framework that’s supported, but it paves the way for adding
support for additional frameworks. REST Assured is one that users seem
particularly interested in (see gh-80 and gh-102).
Closes gh-107
