I have a function as follows
pub fn registration(student_id: &T::StudentId, registrar: &T::RegistrarID) {
// More code here.
if num_of_students < student_limit {
Self::function_one(®istrar, &num_of_students);
} else {
Self::function_two(&num_of_students);
}
}
In unit tests, I am planning to check whether function_one
or function_two
was called.
#[test]
fn registration_more_students_should_call_functon_one() {
with_test_data(
&mut TestBuilder::default().num_of_students(1000).build(),
|| {
//assert_called!(module_name::registration("TV:009", "DF-000-09"));
},
);
}
How can I test if a function was called in Rust?
Here is a naïve attempt using
#[cfg(test)]
in multiple places:The code is loosely based on the snippets that you provided. There is a
Registration
struct that holds a list of student names, two methodsfunction_1
andfunction_2
for registering students, and a functionf
that chooses betweenfunction_1
andfunction_2
depending o how many students there are.During tests,
Registration
is compiled with an additional Boolean variablefunction_1_called
. This variable is set only iffunction_1
is called (the block of code that does that is also marked with#[cfg(test)]
).In combination, this makes an additional Boolean flag available during the tests, so that you can make assertions like the following one:
Obviously, this could work for structures much more complicated than a single boolean flag (which does not at all mean that you should actually do it).
I cannot comment on whether this is idiomatic in Rust or not. The whole setup feels as if it should be hidden behind fancy macros, so if this style of testing is used in Rust at all, there should already be crates that provide those (or similar) macros.
Strong opinion alert: you are doing your testing wrong. This is on the same level as "how do I test a private method". You shouldn't care about the implementation of
registration
to this level of detail.That being said, if it's actually important to know which
if
branch is taken, then use dependency injection:Once you have done this, then you can see that
registration
calls the appropriate trait function (as shown in the example test).This prevents your production code from having test-specific detritus strewn about while also giving you the ability to be more flexible and test more cases rapidly.
See also: