Skip to content
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

Feature/native wrapper pr #50

Closed
wants to merge 183 commits into from
Closed

Feature/native wrapper pr #50

wants to merge 183 commits into from

Conversation

nonec
Copy link

@nonec nonec commented Jun 8, 2019

I wanted to try the native wrapper for a project. So I updated dependencies and made adjustments to make it work for me. It's also using Swift 5 now.
In the end I tried to clean it up but there might be some more necessary.
Made it run on Travis CI and adjusted the tests to pass.

I would be happy to receive feedback :-)

stephengroat and others added 30 commits January 4, 2018 15:37
Wait on verify to complete before allowing tests to continue
Updates README to encourage usage of pact-ruby-standalone
Update project and dependencies for Swift 4.2
@nonec
Copy link
Author

nonec commented Jan 30, 2020

  • Was the only reason to split the rust binary because of the file size? I used git lfs last time https://git-lfs.github.com/ While I don't think there is any problem in theory in splitting it as you have, it might just be more tricky to upgrade the libs in the future.

I just realised I maybe even tried git-lfs before, but it's not possible to push with git-lfs to a fork.

@@ -0,0 +1,4 @@
tap 'pact-foundation/pact-ruby-standalone'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid having these changes that were not made by you in the PR I would encourage you to rebase origin:master onto your fork:branchPR, then force push (onto your fork:branchPR!!!) the new history.

That way any of the changes made to origin will not show up in your PR.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: (for me)
yes, I agree. I'll have to see when I have time for this. Since I think this is what I did the last time.

@@ -1,5 +1,74 @@
# 0.7.1 - Bugfix Release
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same applies here regarding rebasing on your PR branch. You haven't made this changes, have you? Therefore they should not be part of your PR. 🤷

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, like above

github "SwiftyJSON/SwiftyJSON" ~> 4.0
github "Thomvis/BrightFutures" ~> 8.0
github "Quick/Nimble" ~> 8.0
github "SwiftyJSON/SwiftyJSON" ~> 5.0.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After having Codable available to us since Swift 4, I'd encourage you to avoid bringing in more dependencies for things that Swift can do for by just using what Foundation provides.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also something I agree on. Original the branch was done by @andrewspinks . When I first started working on this my goal was to get it to a point that it can be merged back.
Since Codable came up I thought about this, but the top priority was to get everything else working right first.

@@ -1 +1,2 @@
github "Quick/Quick" ~> 1.1
github "Quick/Quick" ~> 2.0
github "AliSoftware/OHHTTPStubs"
Copy link
Contributor

@surpher surpher Apr 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is not you @nonec but if you run carthage update now it will pull version 9.0.0 and it will break current implementation of tests as this dependency dropped OH prefix from all its class names. All it will bring is a headache. :|

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a headache, yes :|

@@ -3,8 +3,8 @@ import Foundation
extension Dictionary {
public func merge(dictionary: [Key: Value]) -> [Key: Value] {
var newDictionary: [Key: Value] = self
for (key, value) in dictionary {
newDictionary[key] = value
for (dictKey, value) in dictionary {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpicking here... The newDictionary already defines it as [Key: Value], following the convention would make sense.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you talking about the type [Key: Value] or the naming (dictKey, value)?

import SwiftPactServer
#endif

public class NativeMockServerWrapper: MockServer {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is really hard to read through this class where public and private declarations are all over the place. It is hard to read and learn about interface the caller needs to interact with.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's mostly private except the MockServer protocol implementations.
What would you do to improve it?


public class NativeMockServerWrapper: MockServer {
private lazy var port: Int32 = {
return findUnusedPort()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this findUnusedPort() is only called here, why not have the logic encapsulated here? it's a private var too.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO:
yes. I think this grew and probably was used somewhere else before.

private let pactDir: String = ProcessInfo.processInfo.environment["pact_dir"] ?? "/tmp/pacts"
private let shouldWritePacts: Bool

public init(shouldWritePacts: Bool = false) {
Copy link
Contributor

@surpher surpher Apr 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is shouldWritePacts used to have a dry run on tests when it's set to false? Or does it have something to do with Filesystem?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I remember it correctly this was needed for the setup I'm using.
I think part of the problem was this is failing on devices and it only worked for simulators. So I had to control a bit when to write for being able to automate this in our building pipeline.


// iOS json generation adds extra backslashes to "application/json" --> "application\\/json"
// causing the MockServer to fail to parse the file.
let sanitizedString = jsonString!.replacingOccurrences(of: "\\/", with: "/")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sanitisation is occurring in a few places, could pull it out into a reusable method or a String extension.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO:
always a good idea

case write([String: [String: String]])

var method: HTTPMethod {
var method: String {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HTTPMethod.rawValue should be the only place where the mapping of these should occur.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think HTTPMethod was from Alamofire which I removed as a dependency here.
So what would be the todo here?

@@ -46,25 +46,38 @@ open class RubyMockServer: MockServer {

// MARK: URLRequestConvertible
func asURLRequest() throws -> URLRequest {
let url = try Router.baseURLString.asURL()
guard let url = URL(string: Router.baseURLString) else { throw NSError(domain: "", code: 1, userInfo: nil) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A new merge on the origin:master made Router method to throw. This is kind of out of date now. :|

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO:
Yeah, I'll have to see about that

.package(url: "https://github.com/Quick/Quick.git", from: "2.1.0"),
.package(url: "https://github.com/SwiftyJSON/SwiftyJSON.git", from: "5.0.0"),
.package(url: "https://github.com/Thomvis/BrightFutures.git", from: "8.0.0"),
.package(url: "https://github.com/nonec/SwiftPactServer.git", from: "1.0.0"),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of having yet another git repo you rely on due to SPM, you could have it as part of the current project and define dependency as .package(path: "path/to/folder/containing/SwiftPactServer")

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remember thinking about that. I think part of the problem was having big files in that and I couldn't use git-lfs on a fork because that would count into the space of the origin.
I'm not a 100% sure, but I think this would be something to resolve if we ever get this to a mergeable state.

@surpher
Copy link
Contributor

surpher commented Apr 13, 2020

Great job in doing this @nonec ! 👍 I see it still supports pact spect v2? Have you looked into implementing v3 to match the rust pact_mock_server?

I had a scroll through but there is so much of it and there are so many changed files I know are not files you changed. It is very very hard to provide feedback because of that. I did leave a few comments that I think you made and I hope you can take it onboard (or take with you and apply on other projects).

If you do manage to merge/rebase and align your PR with current DiUS/pact-consumer-swift:master so we can see only your changes, I'm happy to provide more constructive and in-depth feedback.

}
}

public func verify(_ pact: Pact) -> Future<String, PactError> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're passing Pact into verify() yet it is not used in the method.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is true. It's part of the protocol (and the ruby implementation uses it). I could just ignore it here (or move away from the ruby alternative and change the protocol)
TODO:


private func writeFile() -> Int32 {
guard shouldWritePacts, checkForPath() else {
return 4
Copy link
Contributor

@surpher surpher Apr 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's really hard to understand what this error would be. I'd suggest you use an enum for these. Something like:

enum VerifyResult {
  case failToWrite
  case failToConnect
  case successWrite
  case successVerifyOnly
  case unknown(String?)
}

Naming could be much better for this example, but you get an idea.
That way when you switch through the case you can read it and understand what is happening (case .successVerifyOnly rather than dealing with 4.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO:
agreed. same is valid for the error handling in setup(_ pact: Pact). I think there was a comment on that before as well.

Copy link
Author

@nonec nonec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job in doing this @nonec ! 👍 I see it still supports pact spect v2? Have you looked into implementing v3 to match the rust pact_mock_server?

I had a scroll through but there is so much of it and there are so many changed files I know are not files you changed. It is very very hard to provide feedback because of that. I did leave a few comments that I think you made and I hope you can take it onboard (or take with you and apply on other projects).

If you do manage to merge/rebase and align your PR with current DiUS/pact-consumer-swift:master so we can see only your changes, I'm happy to provide more constructive and in-depth feedback.

Thanks for taking the time looking at this. I'm sorry this got outdated, again.
At the moment the biggest work to get this started was done by @andrewspinks . I only picked this up (twice), updated it and get it to run.
So yes, atm it supports v2, yes. I'd really like for it to support v3.

Tbh I'm not sure if I'll do this dance once more or I'll just pick up my learnings and start over with something that only uses the native wrapper and implements v3.
Not sure when I'll have time to get into this, either way :|

So for now I tried to answer your comments and added TODOs for myself to go through, when there's time on my side.

@andrewspinks
Copy link
Collaborator

Most of the learnings from this PR / branch have been taken and used in a new project here: https://github.com/surpher/PactSwift The idea is to eventually move that to the pact-foundation once it has stabilized. @nonec it would be awesome if you could take a look at that new project when if you get some spare time. I'm going to close this PR to save it getting even more out of date.

@nonec
Copy link
Author

nonec commented Jun 2, 2020

Most of the learnings from this PR / branch have been taken and used in a new project here: https://github.com/surpher/PactSwift The idea is to eventually move that to the pact-foundation once it has stabilized. @nonec it would be awesome if you could take a look at that new project when if you get some spare time. I'm going to close this PR to save it getting even more out of date.

Oh, that looks great! I hope I'll have some time to look into it soon. Thanks for the heads up!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants