...

• Note functional updates needed for SDKs

Functional Testing

Design

...

Token Transfer

The following tests are focused on Token Transfer:

• transfer-tokens.js

Plan: create new record-obt-data.js test:

• Test single recordobt with bundles

  • Send FIO with Memo

  • Confirm get_obt_data returns correct record for payee and payer

  • Confirm content can be decrypted by payee

    • Include correct content for each content field and confirm it can be read by payee

  • Confirm status field for payee and payer

  • Confirm 2 bundles are deducted

• Test single recordobt with no bundles

  • Same test as above, but with no bundles remaining

• Error testing

  • Send with large content field that is too large

  • record obt with:

    • badly formatted payer_fio_address and payee_fio_address

    • Send character string to fio_request_id

    • payee_fio_public_key that does not own the the payee_fio_address

• Paging testing

FIO Requests

The following tests are focused on FIO Requests:

• fio-request.js

• cancel-funds-request.js

• paging.js > C. get_cancelled_fio_requests paging

Plan:

• Merge cancel-funds-request.js and paging.js > C. get_cancelled_fio_requests paging into fio-request.js

• Add new tests to fio-request.js

New tests:

• FIO Request new tests

  • Create requests and get them into all status types

  • Confirm getter calls return correct information

• Paging testing:

  • get_pending_fio_requests

  • get_sent_fio_requests

  • get_received_fio_requests (pull in the tests that Ed wrote)

Results

• Link to JS tests and description of which test sections were updated/added

• Paste results of tests

Performance Testing

Design

...

• OBT

  • Update chain with 5000 OBT requests

  • Confirm fio.test (transfer-tokens.js, record-obt-data.js) runs cleanly

• FIO Request - General

  • Update chain with 5000 requests of each status each from a different user

  • Confirm fio.test (fio-request.js) runs cleanly

• FIO Request

  • Update chain with 5000 requests of each status for a pair of users (payer and payee)

  • Confirm that both payer and payee are able to retrieve all requests.

Results

• Summary of performance tests that were run and results

...

Release 1 - fio.contracts (Bravo-c1)

After this update and the initial call to migrtrx, new Request and OBT data coming in will be entered into both the old and new tables.

Step 1 introduces the new table structure and adds a new “temporary” action call called migrtrx. This action enables the top 21 block producers to start migrating existing data over to the new formatted index tables.

...

[FIP-1.b] Step 1: Add continuous migration of request and obt data (FIO #182)

The complete migration of data has to happen before fio chain is released. An off chain validation should be done to confirm this.

Release 2 - fio chain (Bravo-chain)

...

Release 3 - fio.contracts (Bravo-c2)

All fio chain nodes should be upgraded prior to rolling out Contract Step 2.

Step 2 does two things:

• Modifies the Request code to stop updating the old tables. After this release, only the new tables will get updated.

• Modifies the  migrtrx call. It will now remove data from the old tables.

...

Release Verification Plan

Casey Gardiner Need this. Add info on your scripts that will verify data, etc.