Is there any tool in rust like gotests in unittest

help
1

by gotests,it can Automatically generate Go test boilerplate from your source code.
but in rust, if we already have a project, how can we build the test file and all the functions quickly without such kind of tool ?

2

I don't think such a tool exists. What would you expect these generated tests to look like?

3

You can put test functions directly next to your code or in a folder marked tests on the same level as src then mark youd test functions with the #[test] attribute. You can run these with cargo test

Edit:
There are a few crates that help you make table based tests, like
https://crates.io/crates/test-case
https://crates.io/crates/rstest
Or property based tests like
https://crates.io/crates/proptest
https://crates.io/crates/quickcheck
There may be more that I'm not aware of, but these ones are the common ones

1 Like
4

I expect the tool to automatically generate some test_xx.rs filsts in ./tests. and each test file may be correspondence to a original rs file. test file includes all the empty initialized test functions . So it could be really easy for us to fill up these test fuctions, just like what gotests do . of course there may be many problems about the private fuctions.

6

[quote="rayna, post:5, topic:41700"]
Thank you for your answer. Actually, i know how cargo test works. what my problem is that: writing test fucntions one by one is really Inefficient for exsiting big project. can we automatically generate test framework or test files with any tool?

7

Can you just use a snippet for this?

For example this is how I might write a snippet for a table-based in vim:

#[test]
fn $1() {
    let inputs = vec![
      ($2, $3),
    ];

    for ($5, should_be) in inputs {
        let got = $4($5);
        assert_eq!(got, should_be);
    }
}

You can see I'm composing a vector of tuples, where each tuple contains my input arguments (the $2 placeholder) and my expected output ($3). Then I iterate over each input and pass each argument to the function, asserting that what I got is equal to what it should_be.

As an aside, using automated tools is probably not the best approach if you're trying to bring a large existing project under test. Normally if a large codebase is untested, the code won't be architected in a way that is amenable to table-based tests for all but the most trivial functionality. You'll typically need to check that state has been mutated correctly, invariants are upheld, and functions are called with the right arguments.

Adding loads of table-based tests to your project might bump test coverage numbers (as measured by standard coverage tools), but because the tests were generated by a computer and not a coder they won't actually be testing the right things unless you've done a lot of manual tweaking... In which case you don't gain much by automating away 5 or 6 lines of boilerplate.

2 Likes
8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.