Skip to content

Commit a4c432c

Browse files
committed
Slightly less bad README
1 parent 1093811 commit a4c432c

1 file changed

Lines changed: 22 additions & 21 deletions

File tree

README.md

Lines changed: 22 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -1,20 +1,19 @@
11
# CheckTestOutput
22

3-
A library for semi-manual tests. Run a function, manually check the output. But only if it is different than last run. Built on git - stage the new version to accept it.
3+
**A library for semi-manual tests. Run a function, manually check the output - only if it is different than last run. Built on git - stage the new version to accept it.**
44

5-
Although it's a nice idea that tests should verify if the results are correct by some smart logic, it not always possible/practical. For example, when testing a transpiler, it would come in handy to solve the halting problem. In that cases, you may end up with an assertion that simply checks if the result is equal to one of the valid outputs and that is annoying to maintain. This project just makes the long `Assert.Equal("....", generatedCode)` less annoying.
6-
7-
The library simply checks that the test output is the same as last time.
8-
It the test output is **compared with its version from git index** and throws an **exception if it does not match**, prints a diff and writes a new version to the working tree.
9-
To accept the new version, you stage the changed file.
10-
Or, to inspect the differences, you can use your favorite diff tool.
5+
Although it's a nice idea that tests should verify if the results are correct by some smart logic, it not always possible/practical. For example, when testing a transpiler, it would come in handy to solve the halting problem. In such cases, you will end up with an `Assert.Equal("some very long code including many \" \" and \n \n, super fun to read and maintain", generatedCode)`. This project just makes the long asserts less annoying.
116

7+
CheckTestOutput simply compares the test output and the last "accepted" test output. When it differs, you get an error.
8+
The test output is **compared with its version from git index** and throws an **exception if it does not match**, prints a diff and writes a new version to the working tree.
9+
To accept the new version, you simply stage the changed file (`git add ...`).
10+
To inspect the differences, you use your favorite diff tool.
1211

1312
## Usage
1413

1514
It requires your project to be in [git version control system](https://git-scm.com/) (it works without git, but does not offer the simple stage-to-accept workflow).
1615
You can use any test framework you want, this thing just throws exceptions -- we'll use XUnit in the examples here.
17-
The `OutputChecker` constructor parameter specifies where are the files with the expected output going to be stored relative to the test file location (it uses [C#/F# caller info attributes](https://docs.microsoft.com/cs-cz/dotnet/csharp/programming-guide/concepts/caller-information)).
16+
The `OutputChecker` constructor parameter specifies where are the output files (relative to the test file location - it uses [C#/F# caller info attributes](https://docs.microsoft.com/cs-cz/dotnet/csharp/programming-guide/concepts/caller-information)).
1817
In this case, it's `./testoutputs`.
1918
The file name will be equal to the caller method name, in this case, `SomeTest.TestString.txt`.
2019

@@ -44,7 +43,7 @@ public void TestLines()
4443
}
4544
```
4645

47-
You can check if the object matches when it is serialized to JSON (using Newtonsoft.Json)
46+
Check if the object matches when it is serialized to JSON (using Newtonsoft.Json)
4847

4948
```csharp
5049
[Fact]
@@ -55,7 +54,7 @@ public void TestObject()
5554
}
5655
```
5756

58-
In case you want to use more that one check in one test, you can give them names (so they don't end up overriding themselves):
57+
To use more that one check in one test, you need to give them names (so they don't end up overriding themselves):
5958

6059
```csharp
6160
[Fact]
@@ -67,7 +66,7 @@ public void TestWithMultipleChecks()
6766
}
6867
```
6968

70-
Or you can combine them into one anonymous JSON object (this is preferable when it's short - you don't end up with so many tiny files):
69+
Alternatively, combine them into one anonymous JSON object. It's generally preferable when the string are short - too many tiny files are annoying:
7170

7271
```csharp
7372
[Fact]
@@ -82,7 +81,7 @@ public void TestObject()
8281
}
8382
```
8483

85-
The `checkName` parameter is also useful for tests with parameters (Theory in XUnit).
84+
The `checkName` parameter is also useful for tests with parameters (`[Theory]` in XUnit).
8685
For example, this way we could test a regular expression:
8786

8887
```csharp
@@ -101,7 +100,7 @@ public void IncrementNumbers(string checkName, string testString)
101100
}
102101
```
103102

104-
The text files have `.txt` file extension by default, if that annoys you because your strings have some specific format and syntax highlighting does not work in text files...
103+
The text files have `.txt` file extension by default, but it's easy to change:
105104

106105
```csharp
107106
[Fact]
@@ -116,27 +115,29 @@ Just keep in mind that dotnet is going to treat these `.cs` files as part of sou
116115

117116
### F#
118117

119-
This library is F# friendly, although it's written in C#:
118+
CheckTestOutput is reasonably F# friendly, although it's written in C#:
120119

121120
```fsharp
122121
open CheckTestOutput
123122
124123
let check = OutputChecker "testoutputs"
125124
126125
[<Fact>]
127-
let ``Simple object processing - UseGenericUnion`` () = task {
126+
let ``Simple object processing - UseGenericUnion`` () =
128127
computeSomething 123 "456"
129128
|> string
130129
|> check.CheckString
131130
132131
// or if you need checkName
133132
check.CheckString ("test string", checkName = "test2")
134-
}
133+
[<Fact>]
134+
let ``Example with anonymous record`` () =
135+
check.CheckJsonObject {| a = 1; b = "tukabel" |}
135136
```
136137

137138
### Non-deterministic strings
138139

139-
If you test string, for example, contains some randomly generated GUIDs it's not possible to test that the output is always the same. You could either make sure that the logic you are testing is fully deterministic, or you can fix it later. CheckTestOutput has a helper functionality which allows you to replace random GUIDs with deterministically generated ones.
140+
If the test output contains some randomly generated UUIDs it isn't possible to test that the output is always the same. To fix the problem, you would either have to use a seeded random generator, or replace the UUIDs after the fact. CheckTestOutput has a helper functionality which allows you to replace random UUIDs with deterministically generated ones.
140141

141142
You can enable it by setting `sanitizeGuids: true` when creating `OutputChecker` (or `sanitizeQuotedGuids` to sanitize GUIDs in quotes):
142143

@@ -153,7 +154,7 @@ public void CheckGuidsJson()
153154
}
154155
```
155156

156-
The sanitization preserves equality - it replaces different GUIDs with different stub string and same GUID with the same string. In this case, the checked JSON will be this:
157+
The sanitization preserves equality - it replaces different UUIDs with different stub string and same UUID with the same string. In this case, the checked JSON will be this:
157158

158159
```json
159160
{
@@ -163,7 +164,7 @@ The sanitization preserves equality - it replaces different GUIDs with different
163164
}
164165
```
165166

166-
You can replace anything that can be found by a regular expression, just specify the regexes in the `nonDeterminismSanitizers` parameter.
167+
While mostly used for UUIDs, we can replace anything that can be found by a regular expression - just specify a list of regular expressions in the `nonDeterminismSanitizers` parameter.
167168

168169
### Custom checks
169170

@@ -189,11 +190,11 @@ For more inspiration, have a look at [CheckExtensions class in the Coberec proje
189190

190191
## Installation
191192

192-
Just install [CheckTestOutput NuGet package](https://www.nuget.org/packages/CheckTestOutput).
193+
[NuGet package](https://www.nuget.org/packages/CheckTestOutput) ¯\_(ツ)_.
193194

194195
```
195196
dotnet add package CheckTestOutput
196197
```
197198

198-
Alternatively, you can just grab the source codes from `src` folder and copy them into your project (it's MIT licensed, so just keep a link to this project in the copied code or something). This project has a dependency on [MedallionShell](https://github.com/madelson/MedallionShell) - an amazing library for executing processes without the glitches of the `Process` class. Also, it has a dependency on [Newtonsoft.Json](https://github.com/JamesNK/Newtonsoft.Json) for the JSON serialization. If you are copying the code you'll probably install these. You can exclude `JsonChecks.cs` file to get rid of Newtonsoft.Json dependency.
199+
Alternatively, you can just grab the source codes from `src` folder and copy them into your project (it's MIT licensed, so just keep a link to this project in the copied code). This library does not have any other dependencies.
199200

0 commit comments

Comments
 (0)