<story><title>Add experimental fuzz test support for Go 1.17</title><url>https://github.com/golang/go/issues/44551</url></story><parent_chain><item><author>latch</author><text>I never understood their reason for the verbose and unfriendly ergonomics:&lt;p&gt;if a != b {
  t.Errorf(&amp;quot;expected %s to be equal to %s&amp;quot;, a, b)
}&lt;p&gt;Instead of something like:&lt;p&gt;t.Expect(a).To.Equal(b)&lt;p&gt;And, of course, it gets uglier when you&amp;#x27;re trying to test a function that returns a error,value tuple, which, again, is something that a more friendly testing library can help with.</text></item><item><author>benhoyt</author><text>Go tests and benchmarks are so easy to write and run: just add TestFoo and BenchmarkFoo functions to a bar_test.go file, and &amp;quot;go test&amp;quot; does the rest. It&amp;#x27;s currently doable, but it requires a 3rd party library (go-fuzz) and a bit of fluffing around. This will make fuzz testing an equally first-class citizen with standard Go tooling (just add FuzzFoo), and as such we&amp;#x27;ll probably see a lot more people testing with fuzzing.&lt;p&gt;I used go-fuzz in GoAWK and it found several bugs (see &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;benhoyt.com&amp;#x2F;writings&amp;#x2F;goawk&amp;#x2F;#fuzz-testing&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;benhoyt.com&amp;#x2F;writings&amp;#x2F;goawk&amp;#x2F;#fuzz-testing&lt;/a&gt;), and almost everyone who&amp;#x27;s done fuzz testing has similar reports. Certainly go-fuzz has found many, many bugs in Go itself: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;dvyukov&amp;#x2F;go-fuzz#trophies&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;dvyukov&amp;#x2F;go-fuzz#trophies&lt;/a&gt;&lt;p&gt;For what it&amp;#x27;s worth, I wrote an article for LWN about the upcoming support for built-in fuzzing in Go: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;lwn.net&amp;#x2F;Articles&amp;#x2F;829242&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;lwn.net&amp;#x2F;Articles&amp;#x2F;829242&amp;#x2F;&lt;/a&gt; (of course, if you want full details, read the full proposal).</text></item></parent_chain><comment><author>benhoyt</author><text>It&amp;#x27;s because the Go philosophy is &amp;quot;tests are code&amp;quot;, so you use the standard language features like != instead of a whole new domain-specific language that you have to learn. I&amp;#x27;ve written more about that here: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;lwn.net&amp;#x2F;Articles&amp;#x2F;821358&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;lwn.net&amp;#x2F;Articles&amp;#x2F;821358&amp;#x2F;&lt;/a&gt;&lt;p&gt;Personally I find the &amp;quot;cutesy&amp;quot; names like Expect(a).To.Equal(b) and It(&amp;quot;should ...&amp;quot;) patronizing and too English-like (code is not a human language). Similarly, I wouldn&amp;#x27;t like a language that made you write:&lt;p&gt;&lt;pre&gt;&lt;code&gt;   Please.Print(1.Plus.2)
   Log.To(Console).Text(&amp;quot;did something&amp;quot;)
&lt;/code&gt;&lt;/pre&gt;
The vanilla Go approach can get a bit verbose when you&amp;#x27;re doing lots of asserts. In that case, you can use standard language features like refactoring things to variables or helper functions, or table-driven tests.&lt;p&gt;But if you really want assert-style code, I like the &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;labix.org&amp;#x2F;gocheck&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;labix.org&amp;#x2F;gocheck&lt;/a&gt; approach:&lt;p&gt;&lt;pre&gt;&lt;code&gt;   c.Assert(a, Equals, b)
&lt;/code&gt;&lt;/pre&gt;
Because there&amp;#x27;s only one function (Assert) and a bunch of comparator names to learn.</text></comment>
<story><title>Add experimental fuzz test support for Go 1.17</title><url>https://github.com/golang/go/issues/44551</url></story><parent_chain><item><author>latch</author><text>I never understood their reason for the verbose and unfriendly ergonomics:&lt;p&gt;if a != b {
  t.Errorf(&amp;quot;expected %s to be equal to %s&amp;quot;, a, b)
}&lt;p&gt;Instead of something like:&lt;p&gt;t.Expect(a).To.Equal(b)&lt;p&gt;And, of course, it gets uglier when you&amp;#x27;re trying to test a function that returns a error,value tuple, which, again, is something that a more friendly testing library can help with.</text></item><item><author>benhoyt</author><text>Go tests and benchmarks are so easy to write and run: just add TestFoo and BenchmarkFoo functions to a bar_test.go file, and &amp;quot;go test&amp;quot; does the rest. It&amp;#x27;s currently doable, but it requires a 3rd party library (go-fuzz) and a bit of fluffing around. This will make fuzz testing an equally first-class citizen with standard Go tooling (just add FuzzFoo), and as such we&amp;#x27;ll probably see a lot more people testing with fuzzing.&lt;p&gt;I used go-fuzz in GoAWK and it found several bugs (see &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;benhoyt.com&amp;#x2F;writings&amp;#x2F;goawk&amp;#x2F;#fuzz-testing&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;benhoyt.com&amp;#x2F;writings&amp;#x2F;goawk&amp;#x2F;#fuzz-testing&lt;/a&gt;), and almost everyone who&amp;#x27;s done fuzz testing has similar reports. Certainly go-fuzz has found many, many bugs in Go itself: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;dvyukov&amp;#x2F;go-fuzz#trophies&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;dvyukov&amp;#x2F;go-fuzz#trophies&lt;/a&gt;&lt;p&gt;For what it&amp;#x27;s worth, I wrote an article for LWN about the upcoming support for built-in fuzzing in Go: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;lwn.net&amp;#x2F;Articles&amp;#x2F;829242&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;lwn.net&amp;#x2F;Articles&amp;#x2F;829242&amp;#x2F;&lt;/a&gt; (of course, if you want full details, read the full proposal).</text></item></parent_chain><comment><author>lhorie</author><text>The fluent API flavor is how jest works in javascript-land, and while it makes the code read ok, it makes for some lousy assertion failure messages.&lt;p&gt;Typically, you get some autogenerated variation of &amp;quot;expected 3, got 5&amp;quot; - which in a large codebase is kinda useless because you don&amp;#x27;t necessarily have context on what the error refers to without going back to the test source code to see where the failure originated from. This is especially problematic with table-based tests or tests with large numbers of assertions where the closest human-readable label might have been described too generically.&lt;p&gt;I much prefer to be able write out &amp;quot;foo broke in such such way: expected %s, got %s&amp;quot; than have the team rely on a machine attempting to generate a description and getting a bad description because the human is encouraged to be too lazy to write a proper description and the test framework is not smart enough to write a proper one for them.</text></comment>