Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposed SSZ test suite format #13

Closed
jannikluhn opened this issue Dec 24, 2018 · 1 comment
Closed

Proposed SSZ test suite format #13

jannikluhn opened this issue Dec 24, 2018 · 1 comment

Comments

@jannikluhn
Copy link
Collaborator

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>
  1. For invalid SSZ:
type: <type def string>
valid: false
ssz: <corrupt serialized value>
description: <string with very short explanation what's wrong>
  1. 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.
eth2TestGenBot referenced this issue in ethereum/eth2.0-tests Feb 6, 2019
Latest commit message from eth2.0-test-generators:

commit e216742b88598e40789d2be59c3b2923615434c1
Merge: 7157761 1390f4a
Author: Danny Ryan <[email protected]>
Date:   Wed Feb 6 11:08:24 2019 -0800

    Merge pull request #8 from jannikluhn/ssz

    Add SSZ test generators
@hwwhww hwwhww transferred this issue from ethereum/eth2.0-tests Feb 14, 2019
@ChihChengLiang
Copy link
Collaborator

Close due to Implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants