Support inline data for fixtures

[arxanas]

It would be good to be able to provide data files inline in the test file somehow, rather than requiring a fixture for every such file, which is the recommended workflow in the docs: https://facebookincubator.github.io/scrut/docs/tutorial/#pattern-test-fixtures.

I don't always want to add a new fixture file for every piece of data I want to run as part of the test:

• Many of them are probably specific to the one test, rather than shared across multiple tests, for which it would make more sense to commit a dedicated fixture file.
• In my particular workflow, I try to run tests on commit messages, so it's not realistic to provide fixture files at all.

Possible solutions

Fixture syntax

You could imagine a syntax like

```scrut-fixture
my-fixture.txt
line 1
line 2
line 3
```

Then scrut might automatically write my-fixture.txt to $TESTDIR

scrut subcommand to read fixtures

Rather than automatically write fixture files, you could create a re-entrant scrut command which could read arbitrary metadata from the test. Perhaps your test would look like

```scrut-fixture
my-fixture.txt
line 1
line 2
line 3
```

```scrut
# determines the current test file from the environment
# and reads the appropriate fixture contents:
$ scrut fixture my-fixture.txt | grep '2'
line 2
```

stdin syntax

It would also work to be able to manually provide stdin. (I believe there is no such syntax right now?) Then you could recover inline data with a passthrough command. For example:

```scrut
$ cat >my-fixture.txt <<EOT
line 1
line 2
line 3
```

I don't think there's a way to provide stdin today?

Note that providing stdin can be meaningfully different compared to piping from a file or subprocess (i.e. the command can potentially observe the difference, depending on the OS), although it might not be an important problem in practice.

[ukautz]

I am not fully sure I understand your use-case. Here is what I got:

• Maintaining fixture files, that are only used in one single scrut test file, is too much effort
• Instead a fixture definition in the scrut test file (where the fixture is used) is simpler
• You suggest to extend the Scrut syntax to allow temporary fixture file maintenance (scrut-fixture)

If that is the case, then I would recommend to just create the fixture on top of the test file like (imo better in $TMPDIR than $TESTDIR, or it will survive test execution). Here an example:

# A test with a unique fixture

## Create a "per file fixture"

```scrut
$ cat << EOF > "$TMPDIR/fixture"
> line 1
> line 2
> EOF
```

## Use the "per file fixture"

```scrut
$ cat "$TMPDIR/fixture" | grep 2
line 2
```

Regarding STDIN: This could be done, but I don't think it would be a good idea. Consider the following two test files:

tests/test-1.md

# Test file 1

Write STDIN to `out` and use it later ..

```scrut
$ STDIN-MAGIC | cat > "$TMPDIR"/out
```

tests/test-2.md

# Test file 2

Write STDIN to `out` and use it later ..

```scrut
$ cat > "$TMPDIR"/out
```

And then you would execute

$ echo FOOBAR | scrut test tests/

Now: Would both test cases receive the same "STDIN"?

The main issue I have with this is that it would break the hermetic bubble, as in: the test result would now depend on runtime input that is not stored in the test definition.