Given a collection of sample projects, this library allows you to verify the samples' output.
It does this by discovering, executing, then verifying output of sample projects in a separate directory or embedded within asciidoctor. In fact, the samples embedded here are verified by ReadmeTest.
The intent of sample-check is to ensure that users of your command-line tool see what you expect them to see.
It handles sample discovery, normalization (semantically equivalent output in different environments), and flexible output verification.
It allows any command-line executable on the PATH to be invoked. You are not limited to Gradle or Java.
While this has an element of integration testing, it is not meant to replace your integration tests unless the logging output is the only result of executing your tool. One cannot verify other side effects of invoking the samples, such as files created or their contents, unless that is explicitly configured.
This library is used to verify the functionality of samples in Gradle documentation.
First things first, you can pull this library down from Gradle’s artifactory repository. This Gradle Kotlin DSL script shows one way to do just that.
plugins {
id("java-library")
}
repositories {
maven {
url = uri("https://repo.gradle.org/gradle/libs")
// `url "https://repo.gradle.org/gradle/libs"` will do for Groovy scripts
}
}
dependencies {
testImplementation("org.gradle:sample-check:0.5.1")
}$ gradle -q build
An external sample consists of a directory containing all the files required to run that sample. It may include tagged content regions that can be extracted into documentation.
You can configure a sample to be tested by creating a file ending with .sample.conf (e.g. hello-world.sample.conf) in a sample project dir.
This is a file in HOCON format that might look something like this:
executable: bash
args: sample.sh
expected-output-file: quickstart.sample.outor maybe a more complex, multi-step sample:
commands: [{
executable: gradle
args: originalInputs incrementalReverse
expected-output-file: originalInputs.out
allow-additional-output: true
}, {
executable: gradle
args: removeOutput incrementalReverse
flags: --quiet
expected-output-file: incrementalTaskRemovedOutput.out
allow-disordered-output: true
}]See Sample Conf fields for a detailed description of all the possible options.
NOTE: There are a bunch of (tested) samples under sample-check/src/test/samples of this repository you can use to understand ways to configure samples.
An embedded sample is one in which the source for the sample is written directly within an Asciidoctor source file.
Use this syntax to allow sample-discovery to extract your sources from the doc, execute the sample-command, and verify the output matches what is declared in the doc.
.Sample title
====
[.testable-sample] // (1)
=====
.hello.rb // (2)
[source,ruby] // (3)
-----
puts "hello, #{ARGV[0]}" // (4)
-----
[.sample-command] // (5)
-----
$ ruby hello.rb world // (6)
hello, world // (7)
-----
=====
====-
Mark blocks containing your source files with the role
testable-sample -
The title of each source block should be the name of the source file
-
All source blocks with a title are extracted to a temporary directory
-
Source code. This can be `include::`d
-
Exemplar will execute the commands in a block with role
sample-command -
Terminal commands should start with "$ ". Everything afterward is executed
-
One or more lines of expected output
[NOTE] All sources have to be under the same block, and you must set the title of source blocks to a valid file name.
You can verify samples either through one of the JUnit Test Runners or use the API.
This library provides 2 JUnit runners SamplesRunner (executes via CLI) and GradleSamplesRunner (executes samples using Gradle TestKit). If you are using GradleSamplesRunner, you will need to add gradleTestKit() and SLF4J binding dependencies as well:
dependencies {
testImplementation(gradleTestKit())
testRuntime("org.slf4j:slf4j-simple:1.7.16")
}NOTE: GradleSamplesRunner supports Java 8 and above and ignores tests when running on Java 7 or lower.
To use them, just create a JUnit test class in your test sources (maybe something like src/integTest/com/example/SamplesIntegrationTest.java, keeping these slow tests separate from your fast unit tests.) and annotate it with which JUnit runner implementation you’d like and where to find samples.
Like this:
package com.example;
import org.junit.runner.RunWith;
import org.gradle.samples.test.runner.GradleSamplesRunner;
import org.gradle.samples.test.runner.SamplesRoot;
@RunWith(GradleSamplesRunner.class)
@SamplesRoot("src/docs/samples")
public class SamplesIntegrationTest {
}When you run this test, it will search recursively under the samples root directory (src/docs/samples in this example) for any file with a *.sample.conf suffix.
Any directory found to have one of these will be treated as a sample project dir (nesting sample projects is allowed).
The test runner will copy each sample project to a temporary location, invoke the configured commands, and capture and verify logging output.
Use of the JUnit runners is preferred, as discovery, output normalization, and reporting are handled for you. If you want to write custom samples verification or you’re using a different test framework, by all means go ahead :) — please contribute back runners or normalizers you find useful!
You can get some inspiration for API use from SamplesRunner and GradleSamplesRunner.
Command execution is handled in the org.gradle.samples.executor.* classes, some output normalizers are provided in the org.gradle.samples.test.normalizer package, and output verification is handled by classes in the org.gradle.samples.test.verifier package.
You might want to verify more than just log output, so this library includes JUnit rules that allow you to easily copy sample projects to a temporarily location for other verification. Here is an example of a test that demonstrates use of the @Sample and @UsesSample rules.
package com.example;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.TemporaryFolder;
import org.gradle.samples.test.rule.Sample;
import org.gradle.samples.test.rule.UsesSample;
public class BasicSampleTest {
@Rule
public TemporaryFolder temporaryFolder = new TemporaryFolder();
@Rule
public Sample sample = Sample.from("src/test/samples/gradle")
.into(temporaryFolder)
.withDefaultSample("basic-sample");
@Test
void verifyDefaultSample() {
assert sample.getDir() == new File(temporaryFolder.getRoot(), "samples/basic-sample");
assert sample.getDir().isDirectory();
assert new File(sample.getDir(), "build.gradle").isFile();
// TODO(You): Execute what you wish in the sample project
// TODO(You): Verify file contents or whatever you want
}
@Test
@UsesSample("composite-sample/basic")
void verifyOtherSample() {
// TODO(You): Utilize sample project under samples/composite-sample/basic
}
}One of executable or commands are required at the root.
If executable is found, the sample will be considered a single-command sample.
Otherwise, commands is expected to be an Array of Commands:
-
repeated Command
commands— An array of commands to run, in order.
A Command is specified with these fields.
-
required string
executable— Executable to invoke. -
optional string
execution-subdirectory— Working directory in which to invoke the executable. If not specified, the API assumes./(the directory the sample config file is in). -
optional string
args— Arguments for executable. Default is"". -
optional string
flags— CLI flags (separated for tools that require these be provided in a certain order). Default is"". -
optional string
expected-output-file— Relative path from sample config file to a readable file to compare actual output to. Default isnull. If not specified, output verification is not performed. -
optional boolean
expect-failure— Invoking this command is expected to produce a non-zero exit code. Default:false. -
optional boolean
allow-additional-output— Allow extra lines in actual output. Default:false. -
optional boolean
allow-disordered-output— Allow output lines to be in any sequence. Default:false.
sample-check allows actual output to be normalized in cases where output is semantically equivalent.
You can use normalizers by annotating your JUnit test class with @SamplesOutputNormalizers and specifying which normalizers (in order) you’d like to use.
@SamplesOutputNormalizers({JavaObjectSerializationOutputNormalizer.class, FileSeparatorOutputNormalizer.class, GradleOutputNormalizer.class})Custom normalizers must implement the OutputNormalizer interface. The two above are included in sample-check.
sample-check supports modifying all samples before they are executed by implementing the SampleModifier interface and declaring SampleModifiers.
This allows you to do things like set environment properties, change the executable or arguments, and even conditionally change verification based on some logic.
For example, you might prepend a Command that sets up some environment before other commands are run or change expect-failure to true if you know verification conditionally won’t work on Windows.
@SampleModifiers({SetupEnvironmentSampleModifier.class, ExtraCommandArgumentsSampleModifier.class})To allow Gradle itself to run using test versions of Gradle, the GradleSamplesRunner allows a custom installation to be injected using the system property "integTest.gradleHomeDir".
/statusIcon.svg)
