-
Notifications
You must be signed in to change notification settings - Fork 42
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
Ability to generate test cases from file path #163
Comments
Thanks for idea!
I thought about that in the past but I didn't find a way to do it without
ask to the user to change/introduce build.rs script.
So, I'll take another shot to this and take a look to the crate that you
pointed to see if it use some good idea that not involves build.rs script.
Il lun 12 set 2022, 16:22 ajeetdsouza ***@***.***> ha scritto:
… Hey, thanks for creating this! I think a feature to generate tests for
each file matching a certain glob would be great.
An existing crate that does this is test-generator
<https://github.com/frehberg/test-generator>, but building something
similar here would add a lot of value. For example, a user would be able to
create a matrix test where the first parameter is every path matching a
certain glob, and the second parameter is configurable via the #[values()]
attribute.
—
Reply to this email directly, view it on GitHub
<#163>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5Y34IT34C6Q6MHKUTQNWDV544CNANCNFSM6AAAAAAQKQWHFQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
As far as I can tell, test-generator does need a build.rs script (unless it's optional?). |
Unfortunately build script is not optional 😢 . As far as I know it is not possible to access to something else than the annotated block from procedural macro. |
Seems like you should be able to access the filesystem? - however getting the path resolution to work might be tricky. I haven't tried this myself though. |
the crate
|
Ok, I see the trick let base_dir = PathBuf::from(env::var("CARGO_MANIFEST_DIR").expect(
"#[fixture] requires CARGO_MANIFEST_DIR because it's relative to cargo manifest directory",
)); It seams feasible to use this trick to generate a value list. Thanks very much to point it.... I don't have too much time to work on it: a PR would be really appreciated 😄 |
Here's the relevant file for the |
I've already started to implement it but I can work on it just 2 hours for week ... and not every week 😢 Is quite simple to implement the base implementation for the following example #[rstest]
fn test(#[files("glob_path")] path: PathBuf) {
... generate a test for each file
} Later I'll extend the syntax to handle
|
Ok, I completed the first implementation sketch In playground crate you'll find an example of how to use it. If somebody can try it would be really appreciated. THX |
* Moved extract files in RsTestData * Base implementation without test * MVP completed and test example in playground * Make values creation more testable * Revert "Implemented arguments's files parsing" This reverts commit 6a197fd. * Update rstest requirement from 0.16.0 to 0.17.0 (#192) Updates the requirements on [rstest](https://github.com/la10736/rstest) to permit the latest version. - [Release notes](https://github.com/la10736/rstest/releases) - [Changelog](https://github.com/la10736/rstest/blob/master/CHANGELOG.md) - [Commits](0.16.0...0.17.0) --- updated-dependencies: - dependency-name: rstest dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Fix #189 * Call visit_item_fn_mut in a custom visit_item_fn_mut can cause wired behavior because it will also visit inner functions. A clean solution to #189 is to take the responsibility of the two extraction separated. Also we removed the inner visit_item_fn_mut for all others extractions because are useless and can cause also wired bugs * Update changelog * Prepare new version * Make values creation more testable * Missed mod files in rebase * Fix imports * Refactor for testing * Coverage all errors * Introduce exclude parsing * Implemented filter * fix README.md (#194) (cherry picked from commit 4378e0e) * Fixed tests for last rust version * Use relative path to make regex cross platform * Introduce logic to accept or reject dot files * Implement sort and multiple glob (missed parsing) * Implemented support for more exclude * Implement parsing new syntax (include_dot_files and multiple files and exclude attributes). Tests about new syntax and error. Missed: - error should point attributes and not arguments - Docs - Refactoring (clean code) - Test E2E - Change log * Now error point to attributes * Refactor * Refactor * Add licenses (#196) Symlink license files from the parent directory so that crates are created with them. Needed for distribution especially for the MIT license. Signed-off-by: Michel Alexandre Salim <salimma@fedoraproject.org> * Fixed docs: example in wrong section * Docs * Changelog * E2E test * Move tests on sanitize_ident near to implementation --------- Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: Michel Alexandre Salim <salimma@fedoraproject.org> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: kenkoooo <kenkou.n@gmail.com> Co-authored-by: Michel Alexandre Salim <michel@michel-slm.name>
@la10736 Hi, this is a great step forward ! 👍🏻 However this does not cover the case where there can be several test cases per file. For example, let's say we're writing an HTML parser and we want to use the official Web Platform Tests repository for that (html5lib-tests, which provides language-agnostic machine-readable test cases). In this case we'd need an attribute accepting a glob and a mapping function #[rstest]
// The name is probably not right but you get the idea
#[files_mapped_by("tests/**/*.test", map_file)]
fn some_test(case: Testcase) {
assert_passes!(case)
}
struct TestCase { /* ... */ }
fn map_file(path: &Path) -> Vec<TestCase> {
todo!()
} I don't know if it's even possible in current Rust but I'm mentioning it because I've been in this situation a few times and so far I haven't been able to find a library that can handle this. |
I already thought about this. My Idea is to try to implement something like this but is not trivial because the deserialization code should be called by procedural macro.... |
I decided to close this ticket as completed. I'll open a new ones for creating tests from |
Hey, thanks for creating this! I think a feature to generate tests for each file matching a certain glob would be great.
An existing crate that does this is test-generator, but building something similar here would add a lot of value. For example, a user would be able to create a matrix test where the first parameter is every path matching a certain glob, and the second parameter is configurable via the
#[values()]
attribute.The text was updated successfully, but these errors were encountered: