4 ms·

No tests? :( EDIT: my bad, they were inside src/

by jononor 10y ago

cesarb 10y ago
In Rust, it's very common to put tests right next to the code; all functions tagged with #[test] will be run as tests, and examples within the function documentation comments will also be run as tests by default. For instance, randomly looking at the first file in that repository, cache/cache.rs, you can see at the end a submodule tagged with #[cfg(test)] (meaning it will be compiled only when running the tests), and within it several functions tagged with #[test].
- christophilus 10y ago
  I can't figure out whether or not I like this convention. I used to work with a guy who did the same thing with C++ and C# tests: right there alongside the code they tested. On the one hand, it is nice to have all of the relevant code in one place for context. On the other hand, it muddied up the actual business logic with tests, so you had to perform some mental work to figure out whether the code you were looking at was for production use or only for testing.
  - ryeguy 10y ago
    It's worth noting this convention is only for unit tests. Integration tests traditionally have their own test directory and files. Because of this, the file-inlined test code you see is normally relatively simple and shouldn't have a ton of extra helper functions and setup and such. The majority of the code should just be test cases themselves, which are clearly marked with #[test].
  - Yoric 10y ago
    Note that Rust lets you put tests in tests/ instead of src/. So typically, you put short unit tests in src/ and longer/integration tests in tests/. Oh, and examples that show up in the documentation are also run alongside tests. Also, the compiler will tell you if you have code that's not labelled with #[cfg(test)] but is designed to run only in tests.
    - tyoverby 10y ago
      The big difference with `tests/` is that they have to be integration tests. This means that you can't test private functions from there.
      - Manishearth 10y ago
        Not .. exactly. An integration test usually tests an entire application at once. `tests/` can still test things in the public API (indeed, we do this in Servo a lot) without being an integration test. The point is that some unit tests cannot be written in tests/, whereas all integration tests can be.
  - Sean1708 10y ago
    It's so that you can do unit testing without having to do weird things like airing your privates in tests, since private modules/functions/etc. aren't visible to your integration tests (which live in tests/ and basically just use your code as a library).
  - Tuna-Fish 10y ago
    I started liking this convention when I started considering the tests documentation. In my code, the first unit test for any function is always the simple common case, and having that right next to the function usually makes the code easier to read.
    - steveklabnik 10y ago
      You should move it to a documentation block, given that doc examples are also run as tests. Then your users can see them too. Win-win!
tedmielczarek 10y ago
It does have a bunch of tests, although probably not enough. I've been meaning to add code coverage stats to its CI, although I've only used kcov for Rust code coverage so far, and that only works on Linux it wouldn't reflect reality very well. I've done a lot of work on test automation at Mozilla over the years so automated testing is pretty important to me. :) I've tried to write unit tests where they made sense, they're generally placed within the relevant source file in the tree, like the cache tests here: https://github.com/mozilla/sccache/blob/6eadccc9d6752747766d550388590199d87f23a5/src/cache/cache.rs#L263 https://github.com/mozilla/sccache/blob/6eadccc9d6752747766d... I also wrote some higher-level tests that test the server functionality: https://github.com/mozilla/sccache/blob/master/src/test/tests.rs https://github.com/mozilla/sccache/blob/master/src/test/test... I rolled my own set of traits and structs to mock process execution for those tests so they would run independent of the compilers installed on the system: https://github.com/mozilla/sccache/blob/master/src/mock_command.rs https://github.com/mozilla/sccache/blob/master/src/mock_comm... I actually like how that code turned out, I've thought about cleaning it up and publishing it as a standalone crate. Rust doesn't have a real test mocking solution yet, and even if it did this is a special case since the standard library's process execution types don't implement a trait that could be mocked. As development went on I realized I didn't have automated tests that tested the whole program, especially running against real compilers (which is important given that the tool is a compiler wrapper), so I wrote some "system" tests that run the actual binary with an actual compiler and local disk cache and verify that it works as expected: https://github.com/mozilla/sccache/blob/master/src/test/system.rs https://github.com/mozilla/sccache/blob/master/src/test/syst...

No tests? :( EDIT: my bad, they were inside src/

by jononor 10y ago

No tests? :( EDIT: my bad, they were inside src/

In Rust, it's very common to put tests right next to the code; all functions tagged with #[test] will be run as tests, and examples within the function documentation comments will also be run as tests by default. For instance, randomly looking at the first file in that repository, cache/cache.rs, you can see at the end a submodule tagged with #[cfg(test)] (meaning it will be compiled only when running the tests), and within it several functions tagged with #[test].

christophilus 10y ago
I can't figure out whether or not I like this convention. I used to work with a guy who did the same thing with C++ and C# tests: right there alongside the code they tested. On the one hand, it is nice to have all of the relevant code in one place for context. On the other hand, it muddied up the actual business logic with tests, so you had to perform some mental work to figure out whether the code you were looking at was for production use or only for testing.
- ryeguy 10y ago
  It's worth noting this convention is only for unit tests. Integration tests traditionally have their own test directory and files. Because of this, the file-inlined test code you see is normally relatively simple and shouldn't have a ton of extra helper functions and setup and such. The majority of the code should just be test cases themselves, which are clearly marked with #[test].
- Yoric 10y ago
  Note that Rust lets you put tests in tests/ instead of src/. So typically, you put short unit tests in src/ and longer/integration tests in tests/. Oh, and examples that show up in the documentation are also run alongside tests. Also, the compiler will tell you if you have code that's not labelled with #[cfg(test)] but is designed to run only in tests.
  - tyoverby 10y ago
    The big difference with `tests/` is that they have to be integration tests. This means that you can't test private functions from there.
    - Manishearth 10y ago
      Not .. exactly. An integration test usually tests an entire application at once. `tests/` can still test things in the public API (indeed, we do this in Servo a lot) without being an integration test. The point is that some unit tests cannot be written in tests/, whereas all integration tests can be.
- Sean1708 10y ago
  It's so that you can do unit testing without having to do weird things like airing your privates in tests, since private modules/functions/etc. aren't visible to your integration tests (which live in tests/ and basically just use your code as a library).
- Tuna-Fish 10y ago
  I started liking this convention when I started considering the tests documentation. In my code, the first unit test for any function is always the simple common case, and having that right next to the function usually makes the code easier to read.
  - steveklabnik 10y ago
    You should move it to a documentation block, given that doc examples are also run as tests. Then your users can see them too. Win-win!

tedmielczarek 10y ago

It does have a bunch of tests, although probably not enough. I've been meaning to add code coverage stats to its CI, although I've only used kcov for Rust code coverage so far, and that only works on Linux it wouldn't reflect reality very well. I've done a lot of work on test automation at Mozilla over the years so automated testing is pretty important to me. :) I've tried to write unit tests where they made sense, they're generally placed within the relevant source file in the tree, like the cache tests here: https://github.com/mozilla/sccache/blob/6eadccc9d6752747766d550388590199d87f23a5/src/cache/cache.rs#L263 https://github.com/mozilla/sccache/blob/6eadccc9d6752747766d... I also wrote some higher-level tests that test the server functionality: https://github.com/mozilla/sccache/blob/master/src/test/tests.rs https://github.com/mozilla/sccache/blob/master/src/test/test... I rolled my own set of traits and structs to mock process execution for those tests so they would run independent of the compilers installed on the system: https://github.com/mozilla/sccache/blob/master/src/mock_command.rs https://github.com/mozilla/sccache/blob/master/src/mock_comm... I actually like how that code turned out, I've thought about cleaning it up and publishing it as a standalone crate. Rust doesn't have a real test mocking solution yet, and even if it did this is a special case since the standard library's process execution types don't implement a trait that could be mocked. As development went on I realized I didn't have automated tests that tested the whole program, especially running against real compilers (which is important given that the tool is a compiler wrapper), so I wrote some "system" tests that run the actual binary with an actual compiler and local disk cache and verify that it works as expected: https://github.com/mozilla/sccache/blob/master/src/test/system.rs https://github.com/mozilla/sccache/blob/master/src/test/syst...