We should have standardized tests for SSZ serialization and deserialization in a format compatible with the general test format. For this we just need to define

• a name and
• a test case format.

Test suite name

Just SSZ sounds good to me.

Test case format

I propose the following three formats:

1. For valid inputs:

type: <type def string>
valid: true
value: <the value to serialize>
ssz: <serialized value>

2. For invalid SSZ:

type: <type def string>
valid: false
ssz: <corrupt serialized value>
description: <string with very short explanation what's wrong>

3. For values that can't be serialized:

type: <type def string>
valid: false
value: <invalid value>
description: <string with very short explanation what's wrong>

The first test case type should be run in both directions and the results should match. Executing the other two types should check that serializing/deserializing fails in an orderly fashion.

Type definitions

bools, uints, bytes, hashes, and addresses are specified as a string. Examples:

type: bool
type: uint32
type: bytes
type: hash32
type: address

Containers are specified as mappings (note that we don't have to care about order anymore):

type:
  field1: bool
  field2: uint32
  field3: address

Lists are specified as sequences with a single element for the element type:

type: [uint32]
type: [[bool]]
type:
  - field1: address
    field2: [hash32]

Value format

How values are formatted depends on the given type.

• bool: Either true or false
• bytes, hashes, and addresses: 0x prefixed hex strings:

  value: "0x"
  value: "0xaabbcc"

• uints: decimal strings:

  value: "0"
  value: "123"
  value: "-1"

• containers: Mappings from field names to values encoded according to their type:

  value:
    field1: "0xaabbcc"
    field2: "20"
    field3: true
  value: {}

• lists: Sequences of values encoded according to their type:

  value:
    - "0xaa"
    - "0xbb"
    - "0xcc"
  value:
    - field1: true
      field2: false
    - field1: false
      field2: false
  value: []

SSZ format

SSZ input/output should be encoded as 0x prefixed hex. Examples:

ssz: "0xaabbcc"
ssz: "0x"

Example

title: SSZ uint tests
test_suite: ssz
fork: all
version: "0.1"

test_cases:

- type: uint8
  valid: true
  value: "5"
  ssz: "0x05"

- type: uint8
  valid: false
  value: "256"
  description: overflow

- type: uint8
  valid: false
  ssz: "0x0000"
  description: too long

Comments

• Decimal encoded integers were chosen as suggested here to work around limitations in some YAML parsers.
• The motivation for test case type 3 is mostly to check for integer over/underflows and strings that are too long or too short.