When a variable declared in a before block is used in both mutable and immutable way in different unit tests, it will cause a warning in the declaration.

Example (the code is a butchered version of an existing test suite):

demonstrate! {
  describe "CPU" {
    use super::*;

    before { let mut cpu = Cpu::new(); }

    it "initializes" {
      cpu.internal_ram.to_vec().iter().map(|&x| x as u32).sum::<u32>();
    }

    it "NOP (0x00)" {
        assert_cpu_execute(&mut cpu, &[0x00]);
    }
  }
}

The cpu variable needs to be mutable, however, it causes a warning "variable doesn't need to be mutable"

I don't know if this is inevitable or not, as it also happens to ruspec.

In python, I'm used to using "fixtures" in pytest to amortize the cost of loading big blobs of test data over multiple tests.

https://docs.pytest.org/en/stable/fixture.html

A workaround in rust would be just to put all of my tests in one tests, but then the blob still can't be shared between modules or crates.

Does demonstrate avoid calling the setup functions, or does it just automated calling them at the front of each test?

Thanks!

Not sure if it's by design, anyway... :slightly_smiling_face:

RSpec (and ruspec, by extension) allow strings to be used for block names, eg:

    it "test subject" {
      assert_eq!(subject, 10);
    }

I think this is important for a declarative testing framework, as expressivity is crucial - using function names is instead very limiting.

My 10 bitcents :grimacing:

In BDD testing, it's common to use the words "given", "when" and "then" to describe the test units. This patch adds:

• given and when as aliases of describe
• then as an alias to it

Hi, thank you for your hard work!

I'd love to use this library in integration tests and there's only one thing that prevents me from doing that: #[cfg(test)]. Since integration tests are compiled in a separate crate without the test configuration, tests written using demonstrate aren't compiled.

It'd be nice to add some way to hide #[cfg(test)]. I have a few proposals for the syntax. Personally, I like number 2 the best but feel free to go with anything that fits the library philosophy.

Proposal 1 - let the user write it

This might be a breaking change, but it'd be the simplest to implement.

#[cfg(test)]
demonstrate! {
}

Proposal 2 - separate macro

No breaking change, easy implementation, but requires additional macro.

/// this one stays as is - no breaking changes, generates #[cfg(test)]
demonstrate! {
}

/// this one doesn't generate #[cfg(test)]
demonstrate_for_integration_tests! {
}

Proposal 3 - arguments

An optional keyword inside of the macro that says whether or not the #[cfg(test)] should be generated. Not a breaking change, no need for another macro, but needs parser tweaks.

demonstrate! { integration_tests,
}

I'm concerned about two .clone() calls in the src/generate.rs file: https://github.com/austinsheep/demonstrate/blob/4b832d0aa08c948bdf0e415eae73411200293140/src/generate.rs#L21 https://github.com/austinsheep/demonstrate/blob/6954fe6ecf262462f965c3516ea5cc3371ac08bd/src/generate.rs#L61

I'm not sure if these .clone() calls are necessary and if I should consider a different approach as they are cloning each nested Describe and Test block once per generated Root and Describe scope

Still need to:

• [x] Consider if all uses should really be inherited
• [ ] See if it would be worth making inherited uses super::last_segment
• [x] Update inherit.rs comments
• [x] Update library docs
• [x] Update Readme example (maybe change this altogether)
• [ ] Add more examples

In some cases, it's required to share a single instance between tests.

AFAIK, the current macro before is run before each test, so it doesn't work for the cases above.

There is a workaround, which is very ugly though - using lazy_static with phony implementations of Send and Sync, which is... 🤯

My request is therefore to implement the (typical) "before_all" logic, which is executed only once (per context/describe).