[cpprest] Make the generated APIs mockable. #9
Conversation
We want to able to unit test our code that uses the generated API code. In order to do that we need a virtual interface to mock away the generated API code. This PR introduces two new config options for the cpprest generator: * "generateInterfacesForApis" will generate an abstract base class (interface) for all APIs. * "generateGMocksForApis" will additionally generate Google Mock classes for the APIs. This config option of course implies the first one. If the options are not set only minor white space changes will result (see the changes in the petstore example).
bjoernbaeumler
requested review from
rmartinho,
thomasschaub,
stchris and
fvarose
| @@ -110,6 +112,10 @@ public CppRestClientCodegen() { | |||
| addOption(DEFAULT_INCLUDE, | |||
| "The default include statement that should be placed in all headers for including things like the declspec (convention: #include \"Commons.h\" ", | |||
| this.defaultInclude); | |||
| addOption(GENERATE_INTERFACES_FOR_APIS, | |||
| "Generate abstract base classes (interfaces) for APIs. This allows to mocks APIs (e.g. for unit testing)."); | |||
There was a problem hiding this comment.
Should be This allows to **mock** APIs
| @@ -110,6 +112,10 @@ public CppRestClientCodegen() { | |||
| addOption(DEFAULT_INCLUDE, | |||
| "The default include statement that should be placed in all headers for including things like the declspec (convention: #include \"Commons.h\" ", | |||
| this.defaultInclude); | |||
| addOption(GENERATE_INTERFACES_FOR_APIS, | |||
| "Generate abstract base classes (interfaces) for APIs. This allows to mocks APIs (e.g. for unit testing)."); | |||
There was a problem hiding this comment.
I wonder if we should simply force this, and not make it an option.
I agree that the gmock stuff should be optional because we don't want to force users into gmock.
But having interfaces shouldn't impact anyone already using the tool, and "forcing" them on everyone will help make the overall project more maintainable (e.g. if one day the sample code is tested, should there be tests for both versions?).
There was a problem hiding this comment.
My reasoning was that having the interfaces will increase compile and runtime costs (e.g. an additional virtual function call). So if you don't need them, why would you want to pay for them? On the other hand, compared to a HTTP request, a virtual function call is negligible so this argument is not really valid.
Your argument regarding maintainability is certainly right and probably the stronger one, especially for an open source project. So I will remove this config option.
| @@ -35,7 +35,8 @@ namespace api { | |||
|
|
|||
| using namespace io::swagger::client::model; | |||
|
|
|||
| class StoreApi | |||
|
|
|||
There was a problem hiding this comment.
I think we should avoid spurious whitespace changes in generated code as it's just diff noise.
There was a problem hiding this comment.
Now that we always generate the ABCs it's no longer an issue.
swagger-codegen fork: NativeInstruments/swagger-codegen#9
swagger-codegen fork: NativeInstruments/swagger-codegen#9
* Port GMock feature from NativeInstruments swagger-codegen fork: NativeInstruments/swagger-codegen#9 * Update petstore for Mockable APIs * Fix shared_ptr in templates for File params * Add guards in templates for GMock APIs * Regenerate samples without GMocks * Add useful constructors for GMock APIs * Add constructors to API header interface * Update samples with explicit monadic constructors * Add default implementations for destructors
* Port GMock feature from NativeInstruments swagger-codegen fork: NativeInstruments/swagger-codegen#9 * Update petstore for Mockable APIs * Fix shared_ptr in templates for File params * Add guards in templates for GMock APIs * Regenerate samples without GMocks * Add useful constructors for GMock APIs * Add constructors to API header interface * Update samples with explicit monadic constructors * Add default implementations for destructors
We want to able to unit test our code that uses the generated API code.
In order to do that we need a virtual interface to mock away the
generated API code.
This PR introduces two new config options for the cpprest generator:
(interface) for all APIs.
for the APIs. This config option of course implies the first one.
If the options are not set only minor white space changes will result
(see the changes in the petstore example).