I recommend to just use Xcode. However, AppCode may also work and have some desirable tooling.
Use SwiftLint. Follow the install instructions - make sure swiftlint is in
your path.
NOTE: If you get a fatal error regarding sourcekitd, try the following command:
sudo xcode-select -s /Applications/Xcode.app/Contents/DeveloperTo check lint errors, do:
swift tasks.swift lintThe lint command also fixes the errors it can.
The project PDTest contains manual mocks for protocols defined in PDKit.Protocols. Use them, follow their
patterns, create new ones if you need, modify them as you need. Mocks are mostly built and updates on a
needs-basis, but the basic pattern is:
- If the method has no arguments and no return value, use a call count feature:
public var fooCallCount = 0
public func foo() {
foo += 1
}Have tests verify the call count:
XCTAssertEqual(1, mockObject.fooCallCount- Does the mocked method contain arguments? Create a public variable containing the args and append them
during calls. The convention for the variable name is
<method-name>CallArgs:
public var fooCallArgs: [Int]] = []
public func foo(bar: Int) {
resetCallArgs.append(bar)
} foo(bar: 6)
...
PDAssertSingle(6, fooCallArgs)If there are mutliple args, use a tuple to track them in the list:
public var fooCallArgs: [(Int, String)] = []
public func foo(bar: Int, jules: String) {
resetCallArgs.append((bar, jules))
}- Does the mocked method have a return value? Create a variable named
<method-name>ReturnValueand make it settable:
Example:
public var fooReturnValue = 0
public func foo() {
fooReturnValue
} mockObject.fooReturnValue = 500
let actual = mockObject.foo()
XCTAssertEqual(500, actual)- Is your method annoying complex? Well, just allow for a mock implementation, and make it settable
public var fooMockImplementation: () -> () = { }
public func foo() {
fooMockImplementation()
} var wasCalled = false
mockObject.fooMockImplementation = { wasCalled = true }
mockObject.foo()
XCTAssert(wasCalled)