-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type as test case argument #123
Comments
If there's a common trait connecting these types, then you should be able to use |
Thanks for the quick reply. That definitely goes into the right direction. Maybe you can help me better if I make it more precise. Roughly what I have implemented (heavily simplified): trait Deserialize: Sized {
fn deserialize(buffer: &Vec<u8>) -> Result<Self, &'static str>;
}
struct Model1 {
attribute1: u8,
}
struct Model2 {
attribute2: u8,
attribute3: u8
}
impl Deserialize for Model1 {
fn deserialize(buffer: &Vec<u8>) -> Result<Self, &'static str> {
// Do some stuff
}
}
impl Deserialize for Model2 {
fn deserialize(buffer: &Vec<u8>) -> Result<Self, &'static str> {
// Do some other stuff than in Model1
}
} How would I now test this? I would like to test |
All right, it looks that this is slightly different than I anticipated, however you can still use generics with rust's type coercion:
|
That's already way closer. Thank you! Actually, this gave me an idea on how to replace a lot of my tests through test cases. For the particular case I was asking for I'm trying to test for an error result of the deserialize method. Something like this for example: fn deserialize_small_buffer<T: Deserialize>(min_buff_size: usize) {
let buffer = vec![0u8; min_buff_size - 1];
let result = T::deserialize(&buffer);
assert_eq!(result.is_err(), true);
assert_eq!(result.err().unwrap(), INVALID_BUFFER_SIZE_SMALL_STR);
} How could I realize that? Seems hard to use matches if I want to check for the result. But maybe I'm missing something. |
I realized after writing my comment that you can't really provide the
nor
would work. I could expect that there's a way to overcome this issue with
but this ain't the prettiest solution. There are however closure validators https://github.com/frondeus/test-case/wiki/Syntax#closure-validator and function validators https://github.com/frondeus/test-case/wiki/Syntax#function-validator you can look at. In the latter case you may be able to create a tester method that's also generic, eg.:
|
I also tried out that idea. Works for now and would be a solution I can work with for now. What I don't like about the two solutions you mentioned, is that I have to hard-code the error message. Would be nicer to use the const instead. So I can change the error message later and that does not break the tests. |
This should be possible without use of |
Can you help me out. How would I do this here? |
Just for the record. With someting like this I got it to work. #[test_case(b"input" => matches Result::<Model1, _>::Err(x) if x == SOME_ERROR_STRING_CONST)] @luke-biel Thanks for the help! |
I have some test cases that shall test the same method, but the different implementations of it. So I have multiple structs this method is implemented for. I was thinking about writing a macro and solve the relevant method call using something like this:
This is working fine. However, I wondered if it is possible to do something similar with the
test_case
crate.The text was updated successfully, but these errors were encountered: