In-language Sway Testing

[SilentCicero]

Here I propose a simple test harness plugin, allowing tests in Sway.

Essentially you have a simple library, which contains a few asserts (assert_eq, assert_neq, etc.). Call it swest: Sway+Test.

Tests are written in a Sway script using the asserts. A plugin is installed, say swest. What does swest plugin do? Simple, it runs the script, picks up the logs, and interprets the log data as a test output (similar too many other harnesses).

The benefit of this: tests can be written in Sway without knowing any rust or having to configure a Rust test harness.

Example:

script;

use swest::*;

fn main() {
    let k = 1;
    let v = 2;
    
    assert_eq(k, v, "k == v");
}

CLI:

forc swest

Output:

Sway Testing

1 Test Passing, 1 Test Total

-----

1. "k == v" pass

Log construction:

assert_eq would use something like logd and put all the data in memory, then would encode the appropriate test values. The test harness itself would do the comparison.

[ test type, 2 bytes ] [ first value ] [ second value ] [ message ]

Eventually with annotations we could define the test methods better, and also the harness could pick up what section of tests it's running.

For now this is an idea for a conversation only.

Cavettes:

• Unlike Ethereum, Sway cannot create another contract in-language. So the deploying and contracts would need to be done first, then the deployment details would need to be fed in as transaction data, which is non-trivial.

[mitchmindtree]

I love the idea of being able to write tests for sway in sway.

I don't have many thoughts on your implementation suggestions yet, but just wanted to add a couple motivation points that @JoshuaBatty and I were chatting about recently:

• Being able to remove the user's dependency on cargo would be a huge win, and make a lot of the issues we have around synchronising rustc version compatibility with forc-generated test harnesses totally disappear.
• Would also potentially remove the massive wait that's required the first time the user does forc test due to cargo needing to build the fuel-* and fuels-* crates and their dependencies.
• Would solve the issue where forc test becomes flaky inside a cargo workspace. This occurs because forc thinks the project workspace is the directory that encloses Forc.toml, whereas cargo thinks the project workspace is the directory that encloses the workspace-level Cargo.toml which is different. This is even a problem running forc test in the sway repo, as forc project examples are within a subdirectory of the sway cargo workspace.
• I imagine it would also be a lot more comfortable for JS devs who might not be familiar with Rust and just want to use forc and fuels-ts for example.

[SilentCicero]

@mitchmindtree regarding the Forc test point, is there a way to resolve that, i.e. some kind of cargo test scoping we could add to prevent this? I think I've had this problem before and didn't quite understand what was going on.

As for the other points, I agree. I think there is a lot of potential.

We would need a nice programmatic way of deploying contracts, but that's basically it, the other stuff is quite trivial to implement.

[SilentCicero]

Also, is that caveat regarding forc test detailed in the workarounds in the docs @mitchmindtree ?

[nfurfaro]

I'd like to add another motivational point for implementing this:

• It would allow a simple way of unit testing private functions in the module where they're defined.

[adlerjohn]

Superseded by #1832 and #1833