How to test that a file content is correct across multiple OS

Hi, I am following some exercises, and one is about creating a clone of "cat". The problem is with the tests that validate the output. The tests will load a reference file that was created by using the official "cat" command, and then will compare that file content with one created by the rust code.

The problem is, the output seems different(LCRF problems I think, mostly) depending if you run cargo test in windows Powershell, wsl2, pure linux bash, etc. A test that actually pass in ubuntu will fail in wsl/ubuntu

The console output is not really helpful in seeing what is different... It looks identical to me.(this is the output of the "spider" test that compares the output with the reference file)

---- spiders stdout ----
thread 'spiders' panicked at 'Unexpected stdout, failed diff original var
├── original: Don't worry, spiders,
|   I keep house
|   casually.
├── diff:
└── var as str: Don't worry, spiders,
    I keep house
    casually.

command=`"K:\\code\\rust\\learningrust\\catr\\target\\debug\\catr.exe" "tests/inputs/spiders.txt"`
code=0
stdout="Don\'t worry, spiders,\nI keep house\ncasually.\n"
stderr=""
', /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b\library\core\src\ops\function.rs:227:5

Running the same test on linux returns a success.

So, is there a way to get the same test results across multiples OS shell?

Could you share your code?

Sure, the repo is here

The tests are under tests/cli.rs
Expected output are under tests/expected

1 Like

If you can't see the difference with your eyes, you could try hex-dumping the file. That will reveal exact differences byte-by-byte, without relying on any particular character encoding and/or terminal setting. Also, diff.

1 Like

In the past I've just used String::replace to normalize the strings into using \n after reading the files. Since my files never had intentional Windows line ends, it did nothing on Linux and fixed the tests on Windows. Not the most elegant solution but it worked. I'm not familiar with how line ends work on wsl, but I think it's very plausible that the line ends are the problem.