Permalink
Fetching contributors…
Cannot retrieve contributors at this time
277 lines (207 sloc) 12.7 KB

Exemplar - check and present samples for CLI tools

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.

Use cases

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.

Installation

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.

Example 1. Installing with Gradle
build.gradle.kts
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.7.0")
}
$ gradle -q build

Usage

Configuring external samples

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:

sample-check/src/test/samples/cli/quickstart/quickstart.sample.conf
executable: bash
args: sample.sh
expected-output-file: quickstart.sample.out

or maybe a more complex, multi-step sample:

sample-check/src/test/samples/gradle/multi-step-sample/incrementalTaskRemovedOutput.sample.conf
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.

Configuring embedded 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)
-----
=====
====
  1. Mark blocks containing your source files with the role testable-sample

  2. The title of each source block should be the name of the source file

  3. All source blocks with a title are extracted to a temporary directory

  4. Source code. This can be `include::`d

  5. Exemplar will execute the commands in a block with role sample-command

  6. Terminal commands should start with "$ ". Everything afterward is executed

  7. 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.

Verify samples

You can verify samples either through one of the JUnit Test Runners or use the API.

Verifying using a JUnit Runner

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())
    testRuntimeOnly("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:

SamplesRunnerIntegrationTest.java
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.

Verifying using the API

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.

Using Samples for other integration tests

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.

BasicSampleTest.java
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 {
    public TemporaryFolder temporaryFolder = new TemporaryFolder()
    public Sample sample = Sample.from("src/test/samples/gradle")
            .into(temporaryFolder)
            .withDefaultSample("basic-sample")

    @Rule
    public TestRule ruleChain = RuleChain.outerRule(temporaryFolder).around(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
    }
}

External sample.conf reference

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 is null. 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.

Output normalization

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.

Common sample modification

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})

Custom Gradle installation

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".

Contributing

Build status
code of conduct