-
Notifications
You must be signed in to change notification settings - Fork 4
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
Add possibility to specify argument matchers #11
Comments
Another situation I ran into where matchers are necessary is when setting expectations on args that are objects. There it's not enough to use the equality operator. |
correct. that's a weak compare on the reference, not a deep compare. we have more thinking to do on the matchers. I think we agree that a simple matcher scheme ends up being the secret sauce that makes this whole idea truly useful... but keeping it simple is going to be tricky with the language constraints. sigh. |
First idea: It would be possible to define some kind of macro that hides the parameterization. Let's say we have the following mock:
A full call that would look like:
The parameterization with the types used for 'greater', 'any' and 'equal' is just boilerplate and is stuff that the compiler could figure out by itself, but SV doesn't support this. We could maybe replace this with: ``EXPECT_CALL(mock, func). where
Inside we can do the instantiation of each arg matcher with its appropriate args. Each matcher has to be a parameterized class of course, so that we can do:
This is contingent on the fact that it's possible to supply macro arguments that contain brackets (for the constructor args). If I remember correctly it is. We could go one further and define the following macro:
that would hide the stuff from above and be called as:
Notice the extra brackets around the args for the matchers. |
so this is the road I started down yesterday. similar to what you have but so far I think I can avoid the macro and parameterized constructor call... `EXPECT_CALL(ut, functionIntArgReturnVoid).match_args(int_eq(3)); where int_eq ends up being something like... function svmock_matcher int_eq(int m); I suspect I might be on my way to hitting a rookie mistake with a type mismatch somewhere, but I think in the checking we can case(matcher::type) to see which specialization of svmock_matcher is being used and follow to the proper comparison. |
I don't think you can case over types like that. Even if you could, why would you want to case? The matcher is supposed to implement the comparison itself. Something similar to JUnit::Matcher:
The difficulty lies in supplying the matcher with 'val'. |
I've run into the first situation where I would like to write a test that only checks some aspect of an argument (that it's in a certain range, for example) and not for equality with a certain value. It would be great if we could start thinking about how to specify matchers.
Maybe something like:
We could implement something like a "don't care" matcher (equivalent to GMock's "_"), but the syntax will be very verbose (unless we trade off compile time safety), due to the lack of parameter inference/function overloading.
The text was updated successfully, but these errors were encountered: