sweet

Write many tests quickly and cleanly.

Very early stage warning, do not use seriously!

Features

• 🔥 Parallel
• 🕙 Async
• 🌍 WASM UI tests
• ☮️ Intuitive matchers
• 🌈 Pretty output

Quickstart - Native

1. edit cargo.toml

   [dev-dependencies]
   
   sweet = # current version here
   
   
   
   [[example]]
   
   name = "sweet"
   
   path = "test/sweet.rs"
   
   

2. create file test/sweet.rs

   #![feature(imported_main)]
   pub use sweet::*;
   
   sweet! {
     it "works" {
   		// use assertions
   		assert!(true == false);
   		// or pretty matchers
   		expect(true).to_be_false()?;
   		expect("some string").not().to_start_with("some")?;
     }
   }
   

3. run cargo run --example sweet

Quickstart - WASM

1. Follow native quickstart
2. install the helper cli: cargo install forky_cli
3. add some wasm matchers to your test

   //mount a div in a framework of your choice, we'll use leptos here :)
   mount(|cx|view!{cx,<h1>"This is a heading"</h1>});
   expect_el("h1")?.to_contain_text("This is a heading")?;
   

4. run forky sweet
   • requires wasm-bindgen-cli

Features

Performance

Sweet produces a single binary for each crate. The default rust intergration test runner creates a seperate binary for each test, which ramps up compile times, see this blog for more info.

The wasm runner

Args (native)

• filter by filename: cargo run --example sweet -- some_dir/my_test
• -w argument
  • cargo watch -q -x 'run --example sweet -- -w'
  • Clears terminal on each run
  • Returns an exit code zero (cleaner output)

Matchers

Instead of an opaque panic!, matchers provide the runner with enough info to produce a highly descriptive failure:

expect("foobar").not().to_start_with("foo")?;
/*
Expected: NOT to start with 'foo'
Received: foobar
*/

Async Matchers

Lots of web stuff happens at weird times, so we've got helpers like poll_ok, which will wait for 4 seconds before failing.

let _handle = set_timeout(||{
	mount(|cx|view!{cx,<div>"hello world!"</div>});
},Duration::from_millis(100));

poll_ok(||expect_el("div")).await?
	.to_contain_text("hello world!")?;

Informative outputs

• Long running tests show which suite is hanging
  • 
• Failures are highly descriptive
  • 

Misc

Why use [[example]] instead of [[test]]

This makes it easier for the wasm test runner to produce cleaner output, but if you're only running native tests feel free to use [[test]] with harness=false.

What about wasm-bindgen-test?

Sweet has different priorities from wasm-bindgen-test in its current state.

• Interactive - the runner will list all tests and they can be run at-will in the browser.
• UI - Tests are run in a mostly isolated iframe (see TODO)

TODO

• wasm
  • node & headless support
  • seperate interactive runner from tests, currently the runner code, css etc is included.

Reference

• Matchers inspired by jest
• WASM runner inspired by cypress