-
Notifications
You must be signed in to change notification settings - Fork 45
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
DRUP-747 SDKConnector refactoring, mock API responses in tests and extra test for Authentication form #186
Conversation
Figuring out the best way for mocking and implementing it takes more time. Let's get this merged before the next release and I'll continue with the mocking peace in the next sprint. |
The test has only failed because of this: 3541a43 |
|
||
/** | ||
* Service decorator for SDKConnector. | ||
*/ | ||
class SDKConnector extends OriginalSDKConnector implements SDKConnectorInterface { | ||
final class SDKConnector implements SDKConnectorInterface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will force more re-work in the monetization module. Many classes in this module are being marked as final which keeps them from being extended.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked the Monetization module before I created this PR and I haven't found anything that this change would affect or make it impossible to rewrite with encapsulation. (Which is a better design in this case, because we are not trying to build an API around a service which just builds the API client that other services are using.)
@Jaesin I may have missed something, could you give me a concreate example that you see problematic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Double check it, I used what it is currently in the 8.x-1.x branch. The MINT module only depends on the SDKConnectorInterface
and the method that it provides, it does not depend on a concrete implementation in the SDKConnector. 🎉 The MINT module does not use \Drupal\apigee_edge\SDKConnectorInterface::buildClient()
method which has been removed.
@Jaesin let me know if I missed something.
It would be great if this could be in the next release. |
@Jaesin PR updated, it is almost impossible to make a build to pass on Travis thanks for drupal-composer/drupal-scaffold#105 Here is a proof from my local that Authentication form test now passes:
|
@Jaesin Could you finalize the review of this PR, please? My upcoming commits depends on these changes. |
Okay, as I haven't got an approval on this PR yet I pushed new commits. Please review. |
src/SDKConnector.php
Outdated
// We do this because otherwise SDK connector service decorators that | ||
// decorates the getClient() method would not be called. | ||
if ($key === NULL) { | ||
$client = $this->container->get('apigee_edge.sdk_connector')->getClient(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, this is probably a clear sign that this method should not belong to the SDK connector (as a service and interface) because it depends on the current instance of the SDK connector service. So if I could rewrite this completely I would decouple this from the sdk connector. The SDK connector would only build the client, nothing more. Probably it should be renamed to ClientBuilder. It would depend on a new service that could return the saved the Apigee Edge authentication credentials (username/pwd/endpoint/org) from whichever storage the current service uses (by default the Key) and the testConnection() method would be implemented in a separate service as weéé that would depend on the SDK connector (client builder) and the authentication credentials provider service.
But I do not have to think we have a capacity for this level of rewrite.
@Jaesin could you take a look at this PR again? |
Rebased PR from upstream changes. |
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request. Note to project maintainer: This is a terminal state, meaning the ℹ️ Googlers: Go here for more info. |
|
A Googler has manually verified that the CLAs look good. (Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.) ℹ️ Googlers: Go here for more info. |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
I re-based the PR branch to separate out code comment changes. I created another PR for Logic fixes from this PR here: #200 There are three other types of changes here.
The easiest way to review this PR is commit by commit. I don't see the refactoring as necessary to achieve the objective of additional testing of the authentication form but it seems that being able to mock API responses is. There is already an outdated PR (#79) to provide such functionality. If we are working on a solution for this, shouldn't we follow up on that PR and provide a system that will be compatible or work with what's in the |
* Made sure the SDKConnector is open for extension but closed for modification. * As a consequence, the SDKConnector became final. * Merged the buildClient() method with the getClient() method and removed from the interface. * Added missing return types and concretized type of thrown exceptions. * Removed dead-code and unused properties.
The new test case covers: apigee#179 (review)
Rebased the PR from master: https://travis-ci.org/mxr576/apigee-devportal-drupal/builds/536110705 Indeed, this PR contained multiple, kinda unrelated changes and I did not like that either, but I could not merge the smaller pieces without approval in the previous weeks. Originally I thought the SDKConnector refactoring is also required for proper mocking. When I actually started to work on the mocking I saw that there is the other way around. Although I would like to still close the SdkConnector class before the first stable gets released because it should not be considered as an API by developers. It is not an abstract class, it is a concrete implementation that uses Key as storage. If someone needs something else, s/he should not subclass it from SdkConnector, s/he should build a new implementation by implementing the SdkConnectorInterface. This is KISS. I see very for reasons why someone would decouple this service from the module (mostly covered by the debug and the test module :) ), which is another reason why it should be closed. Regarding mock testing, before I started to build this mocking "framework" I checked #79 and I tried to build something that ensures #79 could be easily migrated to the new implementation. What you have built there was a good for a start but it was also too concrete. I was not extensiable enough |
@cnovak @Jaesin So is there a chance to get this in to the stable version? It should have been released in RC5, but communication has stuck again and it has not been added... Friendly reminder that this PR also contains a fix which blocks the next release of the PHP API client. |
#224 has just arrived, it would be great if this PR could be merged before somebody starts extending the old SDKConnector implementation in its custom module. |
Closing this ticket due to new strategy for testing |
For DRUP-747 we have to be able to replace the API client returned by the SDKConnector in a test. This could be possible without refactoring it but it is better for everyone if we do a last refactoring on the SDKConnector service before the stable release.
I wanted to do this refactoring for a long time ago this seems the best time to do that. These changes simplify the logic, apply OOP- and service decorator best practices on the SDKConnector. Because 99% of code relies on the SdkConnector::getClient() method this is a smaller BC breaking change.
Check the commit message for more details.
Latest Travis build: https://travis-ci.org/mxr576/apigee-devportal-drupal/builds/535298059