Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

dinghy_test::test_file_path doesn't work when running tests natively on desktop platform #99

Closed
luser opened this issue Jan 28, 2020 · 4 comments

Comments

@luser
Copy link

luser commented Jan 28, 2020

I tried out dinghy at work where we have some cross-platform Rust code but aren't currently running our Rust tests on any mobile platforms. I got things to work without a lot of trouble (very cool!) but one of our tests had additional data files so I followed the sending more files directions and using dinghy_test::test_file_path worked fine running the tests on Android. However, when I tried to run the tests natively on my mac using cargo test it would fail with Couldn't find test data .... I looked briefly at the dinghy-test source and while there seems to be a branch for non-mobile platforms I'm guessing this isn't exactly supported. I wound up just using cfg to use the existing hardcoded paths to the test files on non-mobile which isn't great but works.

It'd be nice if dinghy_test worked for native desktop tests as well or if at least the documentation reflected the fact that you shouldn't use it for non-mobile testing.

@kali
Copy link
Collaborator

kali commented Jan 29, 2020

Hi!

Thanks for your interest. The main branch is supposed to support the "host" target (native compilation and tests ran locally, very close to what cargo would do).

As far as I can tell, so far, we have handled this on our projects with something like that as a helper in the integration tests:

#[cfg(test)]
fn test_resources() -> std::path::PathBuf {
    dinghy_test::try_test_file_path("resources").unwrap_or("../resources".into())
}

But I agree we may be able to do something a bit better by integrating the helper. I think the rationale against it was to keep dinghy-test as small as possible (without the yaml parser for instance)...

@luser
Copy link
Author

luser commented Jan 29, 2020

That's a totally reasonable position, it'd be great to have an example like the above in the docs. Thanks!

@kali
Copy link
Collaborator

kali commented Jan 30, 2020

good idea. done.

@kali kali closed this as completed Jan 30, 2020
@luser
Copy link
Author

luser commented Jan 30, 2020

Thanks, that's really helpful!

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants