-
Notifications
You must be signed in to change notification settings - Fork 12
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
Spike: Convert try-o-rama tests to Sweettest [WIP] #92
Conversation
We could convert those tests to sweettest. Regarding your comments:
An important argument to keep using Tryorama (even a general argument) is that you're testing the actual JavaScript/TypeScript API that the web app is using. With sweettest you're using the Rust types of your app that Holochain uses, which is handy. But the web app is the one that consumes the zome functions, and Tryorama is a way to test your TS types and functions in that way. |
Yeah I personally lean on the side of "your tests should follow as close to the actual paths that your code follows as possible". And if you have limited resources, focus on E2E tests that touch the broadest paths, even at the cost of longer test suite run time. I opened a ticket in tryorama repo for one option to address the 'sleep' thing (holochain/tryorama#167) . It seems like part of the slow ci is also the time to spin up a nix environment in the test runner. Figuring out how to get that running reliably seems pretty important for the whole ecosystem. I quite like the output format of the node test runner Ava (https://github.com/avajs/ava). Maybe switching to that would give more usable output (I agree that the tape ones are not very helpful). |
I definitely agree that there is advantage in using the TypeScript types that our frontend uses in the tests. @jost-s said it well:
To me this is the only compelling advantage of Tryorama. @mattyg while I agree in principle with this idea:
...I would say that other than the typescript types, all we're testing in these particular tests (beyond the zome function unit tests at the core) is the HC JS client / conductor setup itself -- which has its own tests, no need to test them in our happ tests. So what about the typescript types? Well, best case is that we generate them from the rust structs -- ie the input types for our zome's @guillemcordoba has done some experimenting with https://crates.io/crates/ts-rs -- if we could get this working, and generate the TS types from the Rust types, then would folks be supportive of using Sweettest for these tests -- which, as Jost mentioned, amount to zome function unit tests? |
Closing after chatting with @mattyg — feel free to reopen in the future! |
Making this initial spike to open a discussion -- I find try-o-rama tests to be:
By contrast I find Sweettest to be:
Oh and of course you can directly use your Rust structs as types! Huge benefit.
Here's an apples to apples side by side conversion of the first test, which I find much more pleasant and readable and maintainable in Rust:
I'll post some screenshots on the other points in comments.