Rather than introducing a custom macro, this commit opts to implicitly
configure the snippets attribute instead. The attribute is configured
will the path into which snippets are generated, relative to the
directory that contains the Asciidoctor document that is being
rendered.
The samples and documentation have been updated to use the new
spring-restdocs-asciidoctor module and the implicitly configured
snippets attribute.
Closes gh-297
The sole structural change is to rearrange the build slightly so that,
like the other samples, the version of the Grails sample's REST Docs
dependency is automatically updated.
See gh-250
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
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
The plugin for building the samples assumed that the current working
directory would be the directory containing the project’s build.gradle.
While this is generally true on the command line (it isn’t if
-project-dir is used), it isn’t true in Gradle’s IDE integration. This
was leading to an NPE as the sampleBuild task was being configured
to depend on a null task as a result of not finding the sample’s pom.xml
or build.grade file.
This commit corrects the main build.gradle to configure each sample’s
working directory relative to the root project’s directory, rather
than relying on the working directory. It also improves
SampleBuildConfigurer so that it will throw an exception if it fails to
find a sample’s build.gradle or pom.xml rather than continuing
and triggering an NPE inside Gradle.
Closes gh-185
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
Previously, to see an example of the documentation that can be
produced by Spring REST Docs, users had to clone the repository and
build one of the samples.
This commit makes it easier to see what Spring REST Docs can do by
updating the docs zip that's automatically published to docs.spring.io
to include both the API Guide and the Getting Started Guide from the
RESTful notes sample.
Closes gh-112
Previously, the generated pom files were uncustomised and relied on
Gradle’s default output. Such pom files are problematic for a couple
of reasons: they include test dependencies and they don’t include the
metadata that’s required for publishing to Maven Central.
This commit customises the generated pom files to include the required
metadata and to remove any test dependencies.
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
Previously, users that wanted to document a request field’s constraints
had to roll their own solution. This commit introduces a new API that
makes it easier to document constraints. Support is provided for
discovering Bean Validation constraints and resolving descriptions for
them. The constraint descriptions can then be used as required. For
example, they can included in a field’s description or in an additional
constraints attribute that’s included in an additional table column via
the use of a custom snippet template.
Closes gh-42
This commit introduces a new TemplateEngine abstraction that is used
to produce the documentation snippets. A default JMustache-based
implementation is provided. JMustache has been repackaged and embedded
to prevent unwanted conflicts and side-effects.
By default, snippet templates are loaded from the classpath in the
org.springframework.restdocs.templates package. Default snippet
templates are provided for all of the snippets that can be generated.
Each of these templates is named after the snippet that it will
produce – the snippet {name}.adoc is produced by the snippet template
default-{name}.snippet. A snippet named {name}.snippet, if present,
will be used in preference to the default snippet, thereby allowing
the default snippets to be overriden.
This commit adds support for post-processing a response before it is
documented. Post-processors are provided to pretty-print JSON and XML
responses, remove headers from the response, and mask the hrefs of
Atom- and HAL-formatted links in JSON responses.
Response post-processing is configured prior to configuring the
documentation. For example,
mockMvc.perform(get("/").accept(MediaType.APPLICATION_JSON))
.andExpect(status().isOk())
.andDo(modifyResponseTo(prettyPrintContent(), removeHeaders("a"),
maskLinks()).andDocument("post-processed"));
Closes gh-61
Closes gh-31
Closes gh-54
Previously the path used to document a field had to be dot-separated,
with each segment of the path being used as a key in a map. This made
it impossible to document fields in a payload within an array.
This commit adds support for using [] in a field’s path to represent an
array. For example, the fields in following JSON payload:
{
"id": 67,
“date”: "2015-01-20",
"assets": [
{
"id":356,
"name": "sample"
}
]
}
Can now be documented using the following paths:
- id
- date
- assets[].id
- assets[].name
Closes gh-60
Previously, a custom host was configured by setting the request’s
remote host. This is in correct as the remote host as the client’s host.
The custom port was also being configured by setting the request’s
remote port and server port. Only the latter is required.
This commit correct the logic by setting the request’s server name and
server port when configuring a custom host and custom port respectively.
The tests have been improved by introducing the use of Spring HATEOAS’s
BasicLinkBuilder to verify that the configured request produces the
expected scheme, host and port in any generated links.
Closes gh-44
The MVC test framework provides an alwaysDo method which allows the
configuration of a result handler to be that will be invoked for every
call to perform. Previously, this method could not be used for
producing documentation snippets as the snippets would overwrite each
other.
This commit adds support for writing snippets to a parameterized
output directory. Two parameters are supported: method name and step.
Method name is the name of the currently executing test method. Step
is a count of the number of calls to MockMvc.perform that have been
made in that method.
Closes gh-14
