This framework provides a Swift DSL for generating and verifying Pact contracts. It provides the mechanism for Consumer-Driven Contract Testing between dependent systems where the integration is based on HTTP. PactSwift allows you to test the communication boundaries between your app and services it integrates with.
PactSwift implements Pact Specification v3 and runs the mock service "in-process". No need to set up any external mock services, stubs or extra tools 🎉. It supports contract creation along with client verification. It also supports provider verification and interaction with a Pact broker.
Note: see Upgrading for notes on upgrading and breaking changes.
- Enter
https://github.com/surpher/PactSwiftin Choose Package Repository search bar - Optionally set a minimum version when Choosing Package Options
- Add
PactSwiftto your test target. Do not embed it in your application target.
dependencies: [
.package(url: "https://github.com/surpher/PactSwift.git", .upToNextMinor(from: "0.11.0"))
]Linux Installation Instructions
When using PactSwift on a Linux platform you will need to compile your own libpact_ffi.so library for your Linux distribution from pact-reference/rust/pact_ffi or fetch a Pact FFI Library x.y.z from pact-reference releases.
It is important that the version of libpact_ffi.so you build or fetch is compatible with the header files provided by PactMockServer. See release notes for details.
See /Scripts/build_libpact_ffi for some inspiration building libraries from Rust code. You can also go into pact-swift-examples and look into the Linux example projects. There is one for consumer tests and one for provider verification. They contain the GitHub Workflows where building a pact_ffi .so binary and running Pact tests is automated with scripts.
When testing your project you can either set LD_LIBRARY_PATH pointing to the folder containing your libpact_ffi.so:
export LD_LIBRARY_PATH="/absolute/path/to/your/rust/target/release/:$LD_LIBRARY_PATH"
swift build
swift test -Xlinker -L/absolute/path/to/your/rust/target/release/or you can move your libpact_ffi.so into /usr/local/lib:
mv /path/to/target/release/libpact_ffi.so /usr/local/lib/
swift build
swift test -Xlinker -L/usr/local/lib/NOTE:
PactSwiftis intended to be used in your test target.- If running on
x86_64(Intel machine) see Scripts/carthage (#3019-1, #3019-2, #3201)
- Instantiate a
MockServiceobject by defining pacticipants, - Define the state of the provider for an interaction (one Pact test),
- Define the expected
requestfor the interaction, - Define the expected
responsefor the interaction, - Run the test by making the API request using your API client and assert what you need asserted,
- When running on CI share the generated Pact contract file with your provider (eg: upload to a Pact Broker),
- When automating deployments in a CI step run
can-i-deployand if computer says OK, deploy with confidence!
import XCTest
import PactSwift
@testable import ExampleProject
class PassingTestsExample: XCTestCase {
static var mockService = MockService(consumer: "Example-iOS-app", provider: "some-api-service")
// MARK: - Tests
func testGetUsers() {
// #1 - Declare the interaction's expectations
PassingTestsExample.mockService
// #2 - Define the interaction description and provider state for this specific interaction
.uponReceiving("A request for a list of users")
.given(ProviderState(description: "users exist", params: ["first_name": "John", "last_name": "Tester"])
// #3 - Declare what our client's request will look like
.withRequest(
method: .GET,
path: "/api/users",
)
// #4 - Declare what the provider should respond with
.willRespondWith(
status: 200,
headers: nil, // `nil` means we don't care what the headers returned from the API are.
body: [
"page": Matcher.SomethingLike(1), // We expect an Int, 1 will be used in the unit test
"per_page": Matcher.SomethingLike(20),
"total": ExampleGenerator.RandomInt(min: 20, max: 500), // Expecting an Int between 20 and 500
"total_pages": Matcher.SomethingLike(3),
"data": Matcher.EachLike( // We expect an array of objects
[
"id": ExampleGenerator.RandomUUID(), // We can also use random example generators
"first_name": Matcher.SomethingLike("John"),
"last_name": Matcher.SomethingLike("Tester"),
"renumeration": Matcher.DecimalLike(125_000.00)
]
)
]
)
// #5 - Fire up our API client
let apiClient = RestManager()
// Run a Pact test and assert **our** API client makes the request exactly as we promised above
PassingTestsExample.mockService.run(timeout: 1) { [unowned self] mockServiceURL, done in
// #6 - _Redirect_ your API calls to the address MockService runs on - replace base URL, but path should be the same
apiClient.baseUrl = mockServiceURL
// #7 - Make the API request.
apiClient.getUsers() { users in
// #8 - Test that **our** API client handles the response as expected. (eg: `getUsers() -> [User]`)
XCTAssertEqual(users.count, 20)
XCTAssertEqual(users.first?.firstName, "John")
XCTAssertEqual(users.first?.lastName, "Tester")
// #9 - Always run the callback. Run it in your successful and failing assertions!
// Otherwise your test will time out.
done()
}
}
}
// Another Pact test example...
func testCreateUser() {
PassingTestsExample.mockService
.uponReceiving("A request to create a user")
.given(ProviderState(description: "user does not exist", params: ["first_name": "John", "last_name": "Appleseed"])
.withRequest(
method: .POST,
path: Matcher.RegexLike("/api/group/whoopeedeedoodah/users", term: #"^/\w+/group/([a-z])+/users$"#),
body: [
// You can use matchers and generators here too, but are an anti-pattern.
// You should be able to have full control of your requests.
"first_name": "John",
"last_name": "Appleseed"
]
)
.willRespondWith(
status: 201,
body: [
"identifier": Matcher.FromProviderState(parameter: "userId", value: .string("123e4567-e89b-12d3-a456-426614174000")),
"first_name": "John",
"last_name": "Appleseed"
]
)
let apiClient = RestManager()
PassingTestsExample.mockService.run { mockServiceURL, done in
// trigger your network request and assert the expectations
done()
}
}
// etc.
}MockService holds all the interactions between your consumer and a provider. For each test method, a new instance of XCTestCase class is allocated and its instance setup is executed.
That means each test has it's own instance of var mockService = MockService(). Hence the reason we're using a static var mockService here to keep a reference to one instance of MockService for all the Pact tests. Alternatively you could wrap your mockService into a singleton.
Suggestions to improve this are welcome! See contributing.
References:
By default, generated Pact contracts are written to /tmp/pacts. If you want to specify a directory you want your Pact contracts to be written to, you can pass a URL object with absolute path to the desired directory when instantiating your MockService (Swift only):
MockService(
consumer: "consumer",
provider: "provider",
writePactTo: URL(fileURLWithPath: "/absolute/path/pacts/folder", isDirectory: true)
)Alternatively you can define a PACT_OUTPUT_DIR environment variable (in Run section of your scheme) with the path to directory you want your Pact contracts to be written into.
PactSwift first checks whether URL has been provided when initializing MockService object. If it is not provided it will check for PACT_OUTPUT_DIR environment variable. If env var is not set, it will attempt to write your Pact contract into /tmp/pacts directory.
Note that sandboxed apps (macOS apps) are limited in where they can write Pact contract files to. The default location seems to be the Documents folder in the sandbox (eg: ~/Library/Containers/xyz.example.your-project-name/Data/Documents). Setting the environment variable PACT_OUTPUT_DIR might not work without some extra leg work tweaking various settings. Look at the logs in debug area for the Pact file location.
If your setup is correct and your tests successfully finish, you should see the generated Pact files in your nominated folder as
_consumer_name_-_provider_name_.json.
When running on CI use the pact-broker command line tool to publish your generated Pact file(s) to your Pact Broker or a hosted Pact broker service. That way your API-provider team can always retrieve them from one location, set up web-hooks to trigger provider verification tasks when pacts change. Normally you do this regularly in you CI step/s.
See how you can use a simple Pact Broker Client in your terminal (CI/CD) to upload and tag your Pact files. And most importantly check if you can safely deploy a new version of your app.
In your unit tests suite, prepare a Pact Provider Verification unit test:
- Start your local Provider service
- Optionally, instrument your API with ability to configure provider states
- Run the Provider side verification step
To dynamically retrieve pacts from a Pact Broker for a provider with token authentication, instantiate a PactBroker object with your configuration:
// The provider being verified
let provider = ProviderVerifier.Provider(port: 8080)
// The Pact broker configuration
let pactBroker = PactBroker(
url: URL(string: "https://broker.url/")!,
auth: auth: .token(PactBroker.APIToken("auth-token")),
providerName: "Your API Service Name"
)
// Verification options
let options = ProviderVerifier.Options(
provider: provider,
pactsSource: .broker(pactBroker)
)
// Run the provider verification task
ProviderVerifier().verify(options: options) {
// do something (eg: shutdown the provider)
}To validate Pacts from local folders or specific Pact files use the desired case.
Examples
// All Pact files from a directory
ProviderVerifier()
.verify(options: ProviderVerifier.Options(
provider: provider,
pactsSource: .directories(["/absolute/path/to/directory/containing/pact/files/"])
),
completionBlock: {
// do something
}
)// Only the specific Pact files
pactsSource: .files(["/absolute/path/to/file/consumerName-providerName.json"])// Only the specific Pact files at URL
pactsSource: .urls([URL(string: "https://some.base.url/location/of/pact/consumerName-providerName.json")])To submit the verification results, provide PactBroker.VerificationResults object to pactBroker.
Example
Set the provider version and optional provider version tags. See version numbers for best practices on Pact versioning.
let pactBroker = PactBroker(
url: URL(string: "https://broker.url/")!,
auth: .token("auth-token"),
providerName: "Some API Service",
publishResults: PactBroker.VerificationResults(
providerVersion: "v1.0.0+\(ProcessInfo.processInfo.environment["GITHUB_SHA"])",
providerTags: ["\(ProcessInfo.processInfo.environment["GITHUB_REF"])"]
)
)For a full working example of Provider Verification see Pact-Linux-Provider project in pact-swift-examples repository.
In addition to verbatim value matching, you can use a set of useful matching objects that can increase expressiveness and reduce brittle test cases.
See Wiki page about Matchers for a list of matchers PactSwift implements and their basic usage.
Or peek into /Sources/Matchers/.
In addition to matching, you can use a set of example generators that generate random values each time you run your tests.
In some cases, dates and times may need to be relative to the current date and time, and some things like tokens may have a very short life span.
Example generators help you generate random values and define the rules around them.
See Wiki page about Example Generators for a list of example generators PactSwift implements and their basic usage.
Or peek into /Sources/ExampleGenerators/.
PactSwift can be used in your Objective-C project with a couple of limitations, (e.g. initializers with multiple optional arguments are limited to only one or two available initializers). See Demo projects repository for more examples.
_mockService = [[PFMockService alloc] initWithConsumer: @"Consumer-app"
provider: @"Provider-server"
transferProtocol: TransferProtocolStandard];PF stands for Pact Foundation.
Please feel free to raise any issues as you encounter them, thanks.
See pact-swift-examples for more examples of how to use PactSwift.
See:
This project takes inspiration from pact-consumer-swift and pull request Feature/native wrapper PR.
Logo and branding images provided by @cjmlgrto.