As I added more and more cases, I found the dir structure hard to
navigate. The new structure follows how you read a type:
e.g. struct { F *string } -> struct/ptr_string
This exposed some redundant cases and some missing cases, too.
As I added more and more cases, I found the dir structure hard to
navigate. The new structure follows how you read a type:
e.g. []*string -> slice/ptr_string
This exposed some redundant cases and some missing cases, too.
As I added more and more cases, I found the dir structure hard to
navigate. The new structure follows how you read a type:
e.g. map[string]*string -> map/string/ptr_string
This exposed some redundant cases and some missing cases, too. Now
map[string] is the "main" test case that exercises all the variants of
value types, and the other key types are just to prove that they
basically work.
the unit test uses compatible mode. The benchmarks measure compat,
default, and fastest.
This still fails for strings and slices and maps all over the place.
This fuzzes a type, marshals it with stdlib and json-iterator, compares,
then unmarshals with stdlib and json-iterator and compares. This is
checking for literal, byte-for-byte compatibility.
In every case the test is exactly the same.
It also include benchmark functions to compare stdlib vs json-iterator.
This depends on a couple PRs to be merged in gofuzz.
