Hi all, I want to check the wisdom of the crowd on the following topic:
Suppose I am interested in fuzz testing an API using dvyukov/go-fuzz <https://github.com/dvyukov/go-fuzz>, and the primary API under test accepts relatively complex composite data types itself: func F(*Table) error, where the types below are minimally as complex as this: type Entry struct { Name string Date time.Date Child *Entry // optional Data interface{} // optional and user-defined } type Table struct { Attrs map[string]string Entries []*Entry } go-fuzz expects the fuzz entrypoints to be func Fuzz(data []byte) int, meaning *Table cannot be used directly without some intermediate serialization and deserialization. Suppose that *Table has no regular on-disk format; what would you recommend as the approach to take toward generating an initial corpus so that go-fuzz can explore the search space and generate prospective crashers. I've toyed around a bit with taking representative values and encoding them to disk with encoding/gob and then having go-fuzz deserialize, validate, and reject bad gob value candidates by returning -1. Notwithstanding any issues inherent to encoding/gob, this does not feel like a particularly efficient on account of extraneous exercising of the gob encoding format, when really func F(*Table) error is what I want to exercise (as in commit my CPU cycles toward). Potentially there are a few other ways of encoding *Table, like Protocol Buffers (with caveats), but encoding/binary is definitely out due to the opaque size of *Table. The point still stands: I would ideally not want to exercise the serialization flow so much as handling of the type on which the data is projected. What strategy would you use here? I feel like there should be an obvious choice under my nose that I am somehow omitting. And no, I don't want testing/quick for this, even though it can generate plenty of complex composite types at runtime. With warm regards, Matt T. Proud -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/802159d8-ae45-4758-ac57-3d800bdc406en%40googlegroups.com.
