syn (and other related libraries) have reached 1.x version quite some time ago. It would be very helpful if you could port speculate to use them.

It is worth to consider replacing bench with something else, e.g. criterion. It is de facto a standard now, whereas bench support will be removed from the compiler.

However, using criterion may be not a solution forever, as it is planned to add an ability to integrate custom testing frameworks in Rust, including benchmarks.

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 speculate.rs developers
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT/Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @utkarshkukreti

It should be added to the docs that describe actually creates an object with the name derived from description and created object may shadow other objects from scope if their name collides.

Ideally generated name for the describe object would be something like UUID to never collide with any other object from scope. Or at least print a warning if shadowing did happen.

And release new version.

Would be much appreciated.

Do you think something like this should go in an example in the README? Or update the example spec to include this overriding of values in nested contexts?

I only ask because this a super-useful pattern for re-using test setup with many variations across your specs, and it took me quite a while to figure out exactly how to get this to work, even after re-reading our last exchange on issue #5.

#[cfg(test)]
extern crate speculate;

#[cfg(test)]
use speculate::speculate;

#[macro_use]
extern crate lazy_static;

fn add(a: i32, b: i32) -> i32 {
    a + b
}

speculate! {
    describe "add" {
        lazy_static! { static ref A: i32 = { 1 }; }
        lazy_static! { static ref B: i32 = { 1 }; }
        before { lazy_static! { static ref SUBJECT: i32 = { add(*A, *B) }; } }

        context "when 1 and 1" {
            it "equals 2" {
                assert_eq!(*SUBJECT, 2);
            }
        }

        context "when B is 2" {
            lazy_static! { static ref B: i32 = { 2 }; }

            it "equals 3" {
                assert_eq!(*SUBJECT, 3);
            }

            context "and A is B + 1" {
                lazy_static! { static ref A: i32 = { *B + 1 }; }

                it "equals 5" {
                    assert_eq!(*SUBJECT, 5);
                }
            }
        }
    }
}

Is there a way to do beforeAll? I'm doing some fairly full integration testing and would like to have a database pool setup once.

#![feature(plugin)]
#![plugin(speculate)]

speculate! {
    it "gives useless line numbers in assert macros" {
        assert_eq!(1, 2);
    }
}

gives

running 1 test
test sup::sup::gives useless line numbers in assert macros ... FAILED

failures:

---- sup::sup::gives useless line numbers in assert macros stdout ----
thread 'sup::sup::gives useless line numbers in assert macros' panicked at 'assertion failed: (left == right) && (right == left) (left: 1, right: 2)', tests/line.rs:4

The line number is always the line starting the speculate! macro.

See this issue: SkylerLipthay/interpolate_idents#36

After reviewing #8 (about 5 months old), looks like this crate was cut over to proc-macro system. As proc-macro has recently stabilized, I figured I would ask.

Hey, just started using the lib for before and afters, and it looks great.

It doesn't appear that it statements can handle Results though, is there a way to do something like the statement below and fail with a proper error when the parse fails?

This would be really helpful with integration tests where there I'll almost always be working with some type of potential failure.

speculate! {
  describe "Handle Result" {
    it "can handle" {
      let n: i32 = "some unparsable value".parse()?;
      assert_eq!(5, n)
    }
  }
}

Without it, I'll need to have this code in almost all the test methods:

it "post expression returns valid response" {
  let res = some_request();
  match res {
    Ok(body) => {
      assert_eq!(body, 1000);
    },
    Err(e) => panic!(e.to_string())
  }
}
`

rust-lang/rust#38356

It's going to be stable soon. Finally we can stop chasing changes in the private rustc crates' APIs. Probably a good time to bump to v1.0.0 at the same time.

First off, thanks for making this! I'm just getting started with testing in rust and this is exactly what I was looking for. 🙂

Seemingly, rustfmt refuses to format the code inside the speculate! macro. I haven't used macros much before, so I wanted to check here first before I post an issue to rustfmt.

Do you know of a way to get rustfmt to work correctly with this framework?

If not, please close and i'll create an issue on rustfmt's repo instead.

Here's a small example I'm trying to get to work:

use speculate::speculate;

// This formats correctly
fn add(a: i32, b: i32) -> i32 {
    a + b
}

speculate! {
// Nothing in here formats correctly
        describe "add" {
            test "adds numbers correctly" {
                    assert_eq!(add(1,2), 3);
                }
    }
}

Expected format:

use speculate::speculate;

fn add(a: i32, b: i32) -> i32 {
    a + b
}

speculate! {
    describe "add" {
        test "adds numbers correctly" {
            assert_eq!(add(1,2), 3);
        }
    }
}

Thanks for taking the time to read.

Hello

I was using speculate for a while now but it seems that no evolutions occurs in the past month.

Does this repository is unmaintained?
Does someone take the lead on it to do improvement?

The README currently indicates that one should enter speculate = "0.1.0" in Cargo.toml. However, this version doesn't appear to have been published on crates.io, is that correct?

I noticed the speculate sometimes fails with upstream changes in Rust and you don't know about it since there is no travis integration right now. I suggest you set up travis and add a nightly build job.

Is there anything we can do to achieve parametrization of tests such as pytest has and rstest re-implements?

If not, take this as a feature suggestion. :)

In case you don't know what I mean: tests parametrization generates a bunch of test cases from an iterable of input parameters and injects the values into the tests.

I'd like to segment my tests into multiple sections of a file. For example, a structure would be defined, and then some tests related to this structure would appear in a speculate! block, and another structure would appear, etc. This would look like this:

pub struct Foo(...);

speculate! {
    it "can do things" {
        // Test Foo here.
    }
}

pub struct Bar(...);

speculate! {
    it "can do other things" {
        // Test Bar here.
    }
}

However, speculate always generate a module named speculate, which causes conflicts at the top-level.

The current workaround is to put every speculate macro in a individual, private modules, but it adds an unnecessary layer of nesting.

Instead, it would be nice if one of the following syntaxes would be added:

speculate! module_name { }
speculate! "module_name" { }

or if speculate appended, for example, the current line number to the created module name.

Would it be possible to have an analog to the 'let' and 'subject' features of RSpec, which are lazy and memoized within each test example? In RSpec, this allows nested contexts to override just a single bit of test setup which can be referred to by other test setup?

error[E0624]: method `parse_block` is private
  --> /Users/msiegel/.cargo/registry/src/github.com-1ecc6299db9ec823/speculate-0.0.26/src/parser.rs:38:40
   |
38 |                     let block = parser.parse_block().unwrap();
   |                                        ^^^^^^^^^^^

error[E0624]: method `parse_ident` is private
  --> /Users/msiegel/.cargo/registry/src/github.com-1ecc6299db9ec823/speculate-0.0.26/src/parser.rs:51:40
   |
51 |                     let ident = parser.parse_ident().unwrap();
   |                                        ^^^^^^^^^^^

error[E0624]: method `parse_block` is private
  --> /Users/msiegel/.cargo/registry/src/github.com-1ecc6299db9ec823/speculate-0.0.26/src/parser.rs:53:40
   |
53 |                     let block = parser.parse_block().unwrap();
   |                                        ^^^^^^^^^^^

error[E0624]: method `parse_block` is private
  --> /Users/msiegel/.cargo/registry/src/github.com-1ecc6299db9ec823/speculate-0.0.26/src/parser.rs:65:40
   |
65 |                     before.push(parser.parse_block().unwrap());
   |                                        ^^^^^^^^^^^

error[E0624]: method `parse_block` is private
  --> /Users/msiegel/.cargo/registry/src/github.com-1ecc6299db9ec823/speculate-0.0.26/src/parser.rs:71:39
   |
71 |                     after.push(parser.parse_block().unwrap());
   |                                       ^^^^^^^^^^^

error[E0624]: method `span_fatal` is private
  --> /Users/msiegel/.cargo/registry/src/github.com-1ecc6299db9ec823/speculate-0.0.26/src/parser.rs:85:47
   |
85 |                         panic!("{:?}", parser.span_fatal(span, &message))
   |                                               ^^^^^^^^^^

error[E0624]: method `span_fatal` is private
  --> /Users/msiegel/.cargo/registry/src/github.com-1ecc6299db9ec823/speculate-0.0.26/src/parser.rs:94:35
   |
94 |             panic!("{:?}", parser.span_fatal(span, &message))
   |                                   ^^^^^^^^^^

error: aborting due to 7 previous errors

For more information about this error, try `rustc --explain E0624`.
error: Could not compile `speculate`.

And here's the version of rust:

$ rustup show
Default host: x86_64-apple-darwin

installed toolchains
--------------------

stable-x86_64-apple-darwin
nightly-x86_64-apple-darwin (default)

active toolchain
----------------

nightly-x86_64-apple-darwin (default)
rustc 1.28.0-nightly (a805a2a5e 2018-06-10)

Basically as the title says, how do I use those special attributes to ignore some tests?

I'm currently using #[async_attributes::test] in my api client, but would like to use Speculate to write my tests.

Could async tests be performed with Speculate without using async_std::block_on?

On nightly, I am getting the error:

help: message: called `Result::unwrap()` on an `Err` value: ParseError(Some("failed to parse anything"))

Nightly as of 11/22/2018:

nightly-x86_64-apple-darwin (default)
rustc 1.32.0-nightly (00e03ee57 2018-11-22)

Here's my example_spec.rs:

#![feature(use_extern_macros)]  // Allows loading new procedural macros.

#[cfg(test)]
extern crate speculate;

#[cfg(test)]
use speculate::speculate;  // Must be imported into the current scope.

#[macro_use]
extern crate lazy_static;

fn add(a: i32, b: i32) -> i32 {
    a + b
}

speculate! {
    lazy_static! { static ref A: i32 = { 1 } };
    lazy_static! { static ref B: i32 = { 1 } };

    describe "add" {
        lazy_static! { static ref SUBJECT: i32 = { add(*A, *B) } };

        context "when 1 and 1" {
            it "equals 2" {
                assert_eq!(*SUBJECT, 2);
            }
        }
    }
}