Open GoogleCodeExporter opened 9 years ago
Here is a sketch for one possible approach: getting the typeinfo at runtime.
It initializes an array of typeinfo (that correlates to the vtable offsets)
with the typeinfo for the mocked class by default. As the mock has expectations
set on specific members, the array is filled in with the more specific
typeinfo. (It "learns" as you program the mock.) I don't know of a way to fill
in the (R)C::*() typeinfo ahead of time, even minimally -- that would be
awesome to figure out.
This simple approach is already a huge leap forward. Now when a mock is
misused, I see this in my test runner output insteead of just
"[std::exception]":
protocol/http/appblade/http_cfe_blade_test.cc:66: Failure: http_cfe_blade_tests
-> does_not_create_appblade_when_request_parsing_not_done
an exception was thrown during test: [partial_implementation_exception: bool (Message::*)()]
protocol/http/appblade/http_cfe_blade_test.cc:85: Failure: http_cfe_blade_tests
-> gives_parsed_request_to_appblade_returned_by_manager
an exception was thrown during test: [missing_implementation_exception: Request]
The top failure is an example of when an expectation is set and the member
information is therefore more detailed. The latter failure is an example of
when an expectation for the mock wasn't set, and is therefore less detailed.
Even with the less detail, I can look at the test and see which mock supplied
to my class's ctor needs additional expectations without a debugger.
An alternate approach would be to use a macro (like cgreen), which would allow
us just to capture the text for a given member:
#define expect(mock, member) mock.expect(member, #member)
// ...
void test(void) { mock_object<foo> mock_foo; expect(mock_foo,
foo::method).when().thenReturn(); }
macros violate namespaces, but it may be worth it if we can't fill in more
typeinfo ahead of time.
The next step is to have the partial_implementation_exception provide more
information about which argument/constraint failed comparison.
Original comment by plaztiks...@gmail.com
on 13 Mar 2013 at 1:53
Attachments:
an updated patch:
1) print out the (streamable) arguments supplied to the mock that failed
2) identify the specific argument that didn't match
protocol/http/appblade/http_cfe_blade_test.cc:66: Failure: http_cfe_blade_tests
-> does_not_create_appblade_when_request_parsing_not_done
an exception was thrown during test: [partial_implementation_exception: bool (Message::*)(DataBuf const*, unsigned int) { [???], 1!!! }]
in the output above, the first argument isn't printable. the second argument is
"1", which doesn't match the expectation -- hence the "!!!". it took me days of
messing with m4 to get something working, and I'm not happy with the structure.
obviously some cleanups needs to happen since the dynamic_object and
dynamic_vfunction files are now cluttered a bit.
it would be nice to also include what the when() expectations were --
optimizing away the need to look in the test sources, but I don't know how to
get the Matcher subclass information. it comes out of the tuple as the base
class only.
I'll test in VC++2012 in a day or two. I'd like to test in clang, but mockitopp
in svn doesn't compile with latest clang (a separate bug I filed).
comments very welcome! :)
Original comment by plaztiks...@gmail.com
on 19 Mar 2013 at 1:39
Attachments:
I think this patch really makes a lot of sense to improve overall usability. My
biggest concern is the use of typeid which requires RTTI be enabled. The patch
as is will not compile if -fno-rtti is specified on the command line.
Original comment by trevor.p...@gmail.com
on 7 Sep 2014 at 6:03
Is it acceptable if these features are disabled when RTTI isn't present? Is there a way to reliably test that across compilers at compile-time (preferred) or run-time (ugh)?
Original issue reported on code.google.com by
plaztiks...@gmail.com
on 7 Mar 2013 at 9:55