Implementing `let` (or some kind of state for tests)

[mackwic]

Having a state to inject to each test is an important pre-condition for parallel tests, guaranteeing test independence, and such.

With the current version, all the tests share the same environment (partially or completely) and so can influence themselves. Not good. Not good at all.

I need help to design a way to declare a fixed state that we would inject to all tests. Many questions here. Reach out if the question interest you.

[regexident]

I saw two possible paths, tried them both and came to the following conclusion:

Adding field to struct Context<'a, …>:

Adding a generic environment: Option<Box<FnMut() -> T>> field to Context<'a, T> (defaulting to None) would allow one to set the environment via ctx.environment(|| 42). The Runner<'a, …> would then make sure that ctx.environment got called exactly once per fn describe (tests would fail otherwise). By using FnMut() -> T instead of T one wouldn't have to constrain T to implement Clone or anything.

Pros: The overall API stays the same. But existing tests fail to compile (see "Cons").

Cons: One would have to call ctx.environment(|| ()) on all contexts without environment, just to satisfy the compiler (in order to deduce T). Even if one doesn't use an environment.

Adding argument to fn describe:

Adding a generic environment: T argument to fn describe (and all its variants) would allow one to inject an environment at the root fn (r)describe.

Pros: No type-ambiguities due to explicitly passing the environment at the root.

Cons: Noisy API, imposing higher typing costs on the user due to complexer API.

---

The former approach is far less aggressive when it comes to the amount and depth of necessary code-/API-changes. It however also lacks in usability compared to the latter.

---

Any alternatives worth investigating?

[mackwic]

Yes, I think so.

The rspec design of let works in this way:

describe MyClass do

  let(:par1) { 42 }
  let(:par2) { "abc" }
  let(:parameter) { { first: par1, second: par2 } }

  it { expect(parameter).to eq { first: 42, second: "abc" } }

  context "let can be overriden" do
    let(:parameter) { "hello" }
    it { expect(parameter).to eq "hello" }
  end

  context "as let are lazy, you can override only :par1" do
    let(:par1) { "overriden !" }
    it { expect(parameter).to eq { first: "overriden !", second: "abc" } }
  end
end

This design is very handy, and hard to reproduct in Rust. However, here is something we can do, playing with patterns:

#[derive(Copy, Clone)]
struct State {
    par1: u32,
    par2: String
}

// Let force State to be Sync+Send+Default
impl Let for State {
    pub fn default() -> Self {
        State { par1: 42, par2: String::from("abc")
    }
}

rdescribe("MyClass", |ctx| {

    ctx.with<State>.it("should have a state parameter", |state| { 42 == state.par1 });
    ctx.with<State>.it("should be able to deconstruct the parameter", |State{par1,..}| { 42 == par1 });
});

Copy-ing code from lazy_static, we may even be able to make something like:

rdescribe("MyClass", |ctx| {
    let!(State, {
        par1: u32 = 42;
        par2: String = String::from("abc")
    });
    ctx.with<State>.it("should have a state parameter", |state| { 42 == state.par1 });
    ctx.with<State>.it("should be able to deconstruct the parameter", |State{par1,..}| { 42 == par1 });
});

I like the idea to add a ctx.with<T> which would then change slightly the semantic like so:

rdescribe("MyClass", |ctx| {
    let!(State, {
        par1: u32 = 42;
        par2: String = String::from("abc")
    });

    // rebind ctx should be ok
    let ctx = ctx.with<State>;
    // before now takes the state argument
    ctx.before_all(|&mut state| { state.par1 += 2 }
    ctx.it("should have been incremented by 2", |State{par1, ..}| { 44 == par1 });
});

I am vary on begin with mutable state. I think it may be a bit too complicated for now. I wonder how far we can go with only immutable State (which is the best practice anyway).

What do you think ?

[regexident]

What do you think ?

I like this approach!

I wonder however (and that's why I arrived at those more involved, and let's face it, uglier approaches) how this would work/scale with (nested) state changes (on each nesting level).

From a user's point of view I would like an API that looks something like this:

rdescribe("Inserting into a HashSet", |ctx| {
    ctx.given("an empty HashSet<_>", |ctx| {
        let set = HashSet::new();
        let before = set.len();
        
        ctx.when("inserting an item", set, |ctx, mut set| {
            ctx.before_all(Scope::Context, |set| {
                set.insert(42);
            });
            
            ctx.then("it grows by 1", &set, |set| {
                set.len() == before + 1
            });
            
            ctx.then("it contains the item", &set, |set| {
                set.contains(42)
            });
        });
    });
});

[mackwic]

I like your example a lot. We needed a complete but simple example since the beginning. HashSet could be it. :)

ctx.before_all(Scope::Context, |mut set| {

why Scope::Context ?

You are also right on the problem with nesting. I thought that closures have different scopes, but nested closures share the root scope so I get conflicting implementation for main::{{closure}}::{{closure}}::Subject. :/

I don't think the trait approach can be used in this case.

[regexident]

why Scope::Context ?

Ruby rspec has before(:suite), before(:context) and before(:example). Not actually sure I'd want to copy this though. I prefer my unit tests to contains as little magic as possible.

---

I actually found some time at 33C3 (🤘) to hack on rspec a bit and I think I'm onto something (some kind of combination of the two options I had evaluated earlier).
I'll create a feature branch as soon as I've cleaned it up a bit.

[regexident]

Implemented in #30