Swift Driver Development Guide
- Things to Install
- The Code
- Running Tests
- Writing and Generating Documentation
Things to install
- swiftenv: a command-line tool that allows easy installation of and switching between versions of Swift.
- Use this to install Swift 4.0 if you don’t have it already.
- jazzy: the tool we use to generate documentation.
- swiftlint: the Swift linter we use.
- libmongoc: the MongoDB C driver, which this library wraps. See the installation instructions provided in our README or on the libmongoc docs.
You should clone this repository, as well as the MongoDB Driver specifications. Since this library wraps the MongoDB C Driver, we also recommend cloning mongodb/mongo-c-driver so you have the source code and documentation easily accessible.
From the Command line
make from the project’s root directory.
We do not provide or maintain an already-generated
.xcodeproj in our repository. Instead, you must generate it locally.
To generate the
- Install the Ruby gem
gem install xcodeproj(you may need to
- You’re ready to go! Open
MongoSwift.xcodeprojand build and test as normal.
Why is this necessary? The project requires a customized
copy resources build phase to include various test
.json files. By default, this phase is not included when you run
swift package generate-xcodeproj. So
make project first generates the project, and then uses
xcodeproj to manually add the files to the appropriate targets (see
NOTE: Several of the tests require a mongod instance to be running on the default host/port,
Additionally, please note that each benchmark test runs for a minimum of 1 minute and therefore the entire benchmark suite will take around 20-30 minutes to complete.
You can run tests from Xcode as usual. If you prefer to test from the command line, keep reading.
From the Command Line
Tests can be run from the command line with
make test. By default, this will run all the tests excluding the benchmarks.
To only run particular tests, use the
FILTER environment variable, which is passed as the
filter argument to
swift test. This will run test cases with names matching a regular expression, formatted as follows:
make test FILTER=ClientTests will run
make test FILTER=testInsertOne will only run
To run all of the benchmarks, use
make benchmark (equivalent to
FILTER=MongoSwiftBenchmarks). To run a particular benchmark, use the
FILTER environment variable to specify the name. To have the benchmark results all printed out at the end, run with
make benchmark | python Tests/MongoSwiftBenchmarks/benchmark.py.
Diagnosing Backtraces on Linux
SWIFT-755 documents an outstanding problem on Linux where backtraces do not contain debug symbols. As discussed in this Stack Overflow thread, a
symbolicate-linux-fatal script may be used to add symbols to an existing backtrace. Consider the following:
$ swift test --filter CrashingTest &> crash.log $ symbolicate-linux-fatal /path/to/MongoSwiftPackageTests.xctest crash.log
This will require you to manually provide the path to the compiled test binary (e.g.
Writing and Generating Documentation
We document new code as we write it. We use C-style documentation blocks (
/** ... */) for documentation longer than 3 lines, and triple-slash (
///) for shorter documentation.
Comments that are not documentation should use two slashes (
Our documentation site is automatically generated from the source code using jazzy.
To regenerate the files after making changes, run
make documentation from the project’s root directory. You can then inspect the changes to the site by opening the files in
/docs in your web browser.
We use swiftlint for linting. You can see our configuration in the
.swiftlint.yml file in the project’s root directory. Run
swiftlint in the
/Sources directory to lint all of our files. Running
swiftlint autocorrect will correct some types of violations.
Sublime Text Setup
- Create a feature branch, named by the corresponding JIRA ticket if exists; for example,
- Do your work on the branch.
- Open a pull request on the repository. Make sure you have rebased your branch onto the latest commits on
Once you get the required approvals and your code passes all tests:
- Rebase on master again if needed.
- Build and rerun tests.
- If your code includes any new documentation or changes to documentation, run
make documentationand commit the resulting changes.
- Squash all commits into a single, descriptive commit method, formatted as:
TICKET-NUMBER: Description of changes. For example,
SWIFT-30: Implement WriteConcern type.
- Merge it, or if you don’t have permissions, ask someone to merge it for you.