# Toolchain wrapper test flow

## What?
Currently, toolchain is using the folder `test-cases/wrappers` to maintain and export different test cases wrappers. In this `wrappers` folder, there's two folders `wasm-as` & `wasm-rs` which implement the different cases (in given implementation); this has introduced the problem of maintanance between different implementations, and there are inconsistencies between different test cases.

Then, these test cases wrappers are imported, built and invoked from the client tests (`/js/client/__tests__/e2e/`), guaranteeing:

1- Wrappers are working as expected, based on the codegen + built WASM file (Schema + CLI + WASM packages)
2- Client is handling invocations as expected (Client JS/RS/Py)

## Why?
Now, with the existence of the [wasm test harness](https://github.com/polywrap/wasm-test-harness) we are able to:

a.- easily decouple wrapper test-cases from current monorepo
b.- allow different client implementations to test against the same wrapper implementations, guaranteeing consistency between tests of dif wrap clients
c.- easily maintain different test wrapper with it different implementations (you can check my rationale [here](https://github.com/polywrap/toolchain/issues/1203#issuecomment-1235397015))

## How?
In the WASM test harness, releases has been published so it's easily accessible to anyone that would like to download a set of wrappers based on N version.

In different client repositories, the `wasm-test-harness` repository is being cloned, to copy the `wrappers` folder, and then removed. Also, this allow us to easily access this wrappers using the `http uri resolver`, which can be used if needed.

This approach, even tho sounds clean, it's not the best, being the reason that if someone would like to do changes to the test cases wrappers, it would not be really possible to fetch these built wasm files