Currently tests don't really cover error cases. The tests are mostly for happy path. Maybe we need to cover some more cases especially the cases leading to errors.
Also a remark regarding the testing code.
The helper function deserializes_with_error requires the second parameter to be of generic type T in order to tell deserializer what type to deserialize. For example:
#[derive(Deserialize, PartialEq, Debug)]
enum E {
A(i32, i32),
B { a: i32, b: i32 },
Z(Z),
}
#[derive(Deserialize, PartialEq, Debug)]
struct Z { a: i32, b: i32 };
// currently we do like this:
deserializes_with_error("{ e: 'Z' }", E { e: E::Z(Z { a: 22, b: 16 } }, "some expected error message");
The call to deserializes_with_error looks a bit messy and a bit hard to read. Of course we could move the struct into a local variable and then pass it to the function. But we don't even use the second parameter within the function, and which is more important - we don't need to. The parameter can be removed and then simply write test like this:
Currently tests don't really cover error cases. The tests are mostly for happy path. Maybe we need to cover some more cases especially the cases leading to errors.
Also a remark regarding the testing code. The helper function
deserializes_with_error
requires the second parameter to be of generic type T in order to tell deserializer what type to deserialize. For example:The call to
deserializes_with_error
looks a bit messy and a bit hard to read. Of course we could move the struct into a local variable and then pass it to the function. But we don't even use the second parameter within the function, and which is more important - we don't need to. The parameter can be removed and then simply write test like this:Fortunately, there is not a lot of error-testing code (like 4-6 tests), so fixing it won't take long. If that makes sense, I can do it.