There are two issues I ran into using this library and running integration tests on windows:
- [x] The `new_scene!` macro doesn't add `.exe` to the executable name. I fixed this locally, and I'll open a PR as soon as I've submitted this issue.
- [ ] The library I use that sends output to the terminal uses `\r\n` on windows, making it hard to use the same test fixtures of the expected output. Maybe there's a nice API to support something as common as this? (For now I'm working around it by including the fixtures as strings (`include_str!`) in the test file...)
I need to think about this. It's hard to think of an approach that doesn't take an opinionated stance on whether binaries' output should have platform-dependent newlines, and that also follows the principle of least surprise and K.I.S.S. (e.g. people might not expect all `\r\n` to be replaced with `\n`, and thinking about how to do separate tests just for "correct newlines" will probably give most people headaches)
I agree, it's a hard problem. I don't know the best solution either :|
As a data point: I currently duplicating the fixture files and [using `#[cfg(windows)]` to test against the right one](https://github.com/Apanatshka/cargo-benchcmp/blob/74692d6d99de594b9f54db75b3d450403e2b34cc/tests/integration.rs) (in a sub-optimal way I just noticed).
I stumbled upon this `\r\n` problem through the use of `prettytable-rs` which does platform specific newlines by default. I'd prefer to turn that off and stick my head in the sand over finding out how much code I need to change to consistently use windows newlines on windows. I [requested an option to turn off `\r\n`](https://github.com/phsym/prettytable-rs/issues/33), also because for command-line tools I think there is a case to be made for just following unix standards, since windows isn't much of a command-line platform anyway. If you agree with that, you could also close this issue with "won't fix" 😸