Multi-Wasm Language Ecosystem Infrastructure - Feature Design
==============

## Overview

With more wasm languages being added, we need a better testing infrastructure for these implementations so that we can determine what features are supported, creating a feature matrix for developers to reference when choosing a wasm language.

## FANG (Framing, Assumptions, Non-goals, Goals)

### Framing
Multiple implementation languages (AssemblyScript, Rust, TinyGo). Sometimes not all languages support the same features at the same time. Some might hang behind the others.

### Assumptions

- List what represents basic "core" functionality. For example, invocation, data translation. (edited)
- Assumption - List things that are "non-core", environment (edited)

### Non-Goals
- Have tests for functionality, and not bindings
- Bindings are too opinionated, and there could be multiple "flavors"
- For new Wasm language supports, we do not need to run exhaustive testing between every combination of client & wasm language. These will only before we release we will run this to ensure completeness

### Goals
- Feature matrix for each of the implementation languages
- Testing pipeline to detect feature support
- Each Feature Test Definition should be versioned, and there should be rules about how to update FTDs for both staging & production
- Have tests be separate from the client e2e tests
- create a repository to hold all test cases
- Have tests for binding correctness & logic
- Have clear steps to add support for a new language, to help developers build new language support
- Allow 3rd parties to implement their own language support
- Allow wasm lanagues to run against one "known good" client
- Perform continuous testing for wasm language updates, compare with known feature matrix (golden master), and additionally allow for approval of new "golden masters"
- Perform exhaustive tests before release to ensure every combination works
- Abstracting what represents "language support" outside of the toolchain so that we make extensible for outside developers to make their own language support packages with different tweaks
- Example - AssemblyScript has its own package for bindings and everything
- Allow language supports to define their own build steps / images

## Implementation Details

### Feature Matrix
- "core" functionality
- Invoke
- Sub Invocation
- Data Translation
- Env
- Asyncify Support
- imported Wasm env.memory
- core basic types (Ex: Int, Float, string, etc)
- core collection types (Ex: array, (not sure map supported everywhere))
- "extention" functionality
- extension types
- BigInt
- BigNumber
- Union
- etc

### Testing pipeline to detect feature support
Feature Test Definition:
- schemas + workflows + client trace diffs (cue-lang?)
- Env
- core types
- sub invocation
- etc

To create exhaustive test matrix we must write test descriptions in a language agnostic way and I think workflow can come in handy here.

This will go hand in hand with Test driven development where feature tests are already well-defined before implementation.

### Have tests be separate from the client e2e tests
### create a repository to hold all test cases
Seperate repository that contains all wasm-language-feature-test-harness.

Versioning the workflow that we use for testing feature matrix and different implementation (there can patches and changes in the features that can be captured with the workflow versions)

Test driven versioning?

### Have clear steps to add support for a new language, to help developers build new language support
- Each language support would have a known set of things:
- schema-bindings
- wasm lib
- build steps (build image) --> (export Compiler?)
- test-case wrapper impls

#### Examples
:::info

:::info
## Initial Feedback
- [ ]

### Related
https://github.com/polywrap/technical-council/issues/68

for e2e tests
https://github.com/ethereum/hive

for different kind of tests (tx, evm, etc)
https://github.com/ethereum/tests

:::