-
Notifications
You must be signed in to change notification settings - Fork 68
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
cpp11 branch - issues against reporter #68
Comments
|
I wrote an alternative reporter in order to check the provided interface for usability. Imho the actual version of the Reporter's interface forces tight coupling to hippomocks and is not easily extendable. It would be more flexible to use some kind of ReportFailure(msg, at) and call them from HippoMocks. This would reduce the reporter implementation to 3 Methods only. The key question is, where do you want the message texts to be generated, by HippoMocks or by the reporter. Imho it's easier to make some stardadized texts and parse them afrerwards to whatever format is needed, e.g like CPPUNIT output is formatted in jUnit format and can be easily reused by many tools then. Please give a hint, if the proposal matches your intention, or not. |
The idea from the interface is to have the tight coupling. The message texts should be customizable in the generator, specifically to allow for filtering, selection, printing more data or changing the format of printing so as to integrate with an IDE, test environment, test framework, CI system or such. I intend to have some reporters included specifically for some test frameworks so people can use those for some common use cases - say, using it with GTest or Catch, or with XML or JUnit-compatible output. For example, in the CallMissing callback you get told which call is missing, so you can use that info to selectively print a subset of the mock repo (such as anything that came before this, other calls on the same mock etc.). In ExpectationExceeded you could inform the user about why the call did not match, which calls it looks like and why those did not match. In NoCallMatches you can inform what calls did not match and why they did not match. I can see your point about tight coupling; in this case though it's intentional. Is it an idea to split the responsibilities in two - formatting and reporting? |
According to the Single Responsibility Principle, formatting and reporting should be splitted. |
This is a collector topic. ( No critic, just my thoughts) ;-)
I had a look at the current implementation and this are my remarks so far:
The text was updated successfully, but these errors were encountered: