-
Notifications
You must be signed in to change notification settings - Fork 167
Add data loading test helpers for Swift Testing and draft contributor information about writing tests #1362
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
base: main
Are you sure you want to change the base?
Changes from all commits
951cab6
9cb71ea
bf746cd
8c0a4af
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -166,7 +166,7 @@ If you have commit access, you can run the required tests by commenting the foll | |||||
|
|
||||||
| If you do not have commit access, please ask one of the code owners to trigger them for you. | ||||||
| For more details on Swift-DocC's continuous integration, see the | ||||||
| [Continous Integration](#continuous-integration) section below. | ||||||
| [Continuous Integration](#continuous-integration) section below. | ||||||
|
|
||||||
| ### Introducing source breaking changes | ||||||
|
|
||||||
|
|
@@ -207,7 +207,23 @@ by navigating to the root of the repository and running the following: | |||||
| By running tests locally with the `test` script you will be best prepared for | ||||||
| automated testing in CI as well. | ||||||
|
|
||||||
| ### Testing in Xcode | ||||||
| ### Adding new tests | ||||||
|
|
||||||
| We recommend that you use [Swift Testing](https://developer.apple.com/documentation/testing) when you add new tests. | ||||||
| Currently there are few existing tests to draw inspiration from, so here are a few recommendations: | ||||||
|
|
||||||
| - Prefer small test inputs that ideally use a virtual file system for both reading and writing. | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we have any notes or internal docs on what functions to use, or examples to reference, that use the virtual file system setup? That would be great to point to, if we can.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can probably update each bullet to include an example that's both using Swift Testing and one that uses XCTest. |
||||||
| - Consider using parameterized tests if you're making the same verifications in multiple configurations or on multiple elements. | ||||||
| - Think about what information would be helpful to someone else who might debug that test case if it fails in the future. | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wasn't quite sure what it is that I should do with the thinking about this. I get the reason you're asking for the consideration, but am unsure of how to apply that consideration into a test. Any suggestions? |
||||||
| - Use `#require` rather that force unwrapping for behaviors that would change due to unexpected bugs in the code you're testing. | ||||||
|
|
||||||
| If you're updating an existing test case with additional logic, we appreciate it if you also modernize that test, but we don't expect it. | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
| If the test case is part of a large file, you can create new test suite which contains just the test case that you're modernizing. | ||||||
|
|
||||||
| If you modernize an existing test case, consider not only the syntactical differences between Swift Testing and XCTest, | ||||||
| but also if there are any Swift Testing features or other changes that would make the test case easier to read, maintain, or debug. | ||||||
|
|
||||||
| ### Testing DocC's integration with Xcode | ||||||
|
|
||||||
| You can test a locally built version of Swift-DocC in Xcode 13 or later by setting | ||||||
| the `DOCC_EXEC` build setting to the path of your local `docc`: | ||||||
|
|
||||||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,53 +1,36 @@ | ||
| /* | ||
| This source file is part of the Swift.org open source project | ||
|
|
||
| Copyright (c) 2021 Apple Inc. and the Swift project authors | ||
| Copyright (c) 2021-2025 Apple Inc. and the Swift project authors | ||
| Licensed under Apache License v2.0 with Runtime Library Exception | ||
|
|
||
| See https://swift.org/LICENSE.txt for license information | ||
| See https://swift.org/CONTRIBUTORS.txt for Swift project authors | ||
| */ | ||
|
|
||
| import Foundation | ||
| import XCTest | ||
|
|
||
| import Testing | ||
| import Markdown | ||
|
|
||
| @testable import SwiftDocC | ||
|
|
||
| class ParseDirectiveArgumentsTests: XCTestCase { | ||
| func testEmitsWarningForMissingExpectedCharacter() throws { | ||
| let diagnostic = try XCTUnwrap( | ||
| parse(rawDirective: "@Directive(argument: multiple words)").first | ||
| ) | ||
|
|
||
| XCTAssertEqual(diagnostic.identifier, "org.swift.docc.Directive.MissingExpectedCharacter") | ||
| XCTAssertEqual(diagnostic.severity, .warning) | ||
| } | ||
|
|
||
| func testEmitsWarningForUnexpectedCharacter() throws { | ||
| let diagnostic = try XCTUnwrap( | ||
| parse(rawDirective: "@Directive(argumentA: value, argumentB: multiple words").first | ||
| ) | ||
|
|
||
| XCTAssertEqual(diagnostic.identifier, "org.swift.docc.Directive.MissingExpectedCharacter") | ||
| XCTAssertEqual(diagnostic.severity, .warning) | ||
| } | ||
|
|
||
| func testEmitsWarningsForDuplicateArgument() throws { | ||
| let diagnostic = try XCTUnwrap( | ||
| parse(rawDirective: "@Directive(argumentA: value, argumentA: value").first | ||
| ) | ||
|
|
||
| XCTAssertEqual(diagnostic.identifier, "org.swift.docc.Directive.DuplicateArgument") | ||
| XCTAssertEqual(diagnostic.severity, .warning) | ||
| } | ||
|
|
||
| func parse(rawDirective: String) -> [Diagnostic] { | ||
| let document = Document(parsing: rawDirective, options: .parseBlockDirectives) | ||
|
|
||
| struct ParseDirectiveArgumentsTests { | ||
| @Test(arguments: [ | ||
| // Missing quotation marks around string parameter | ||
| "@Directive(argument: multiple words)": "org.swift.docc.Directive.MissingExpectedCharacter", | ||
| // Missing quotation marks around string parameter in 2nd parameter | ||
| "@Directive(argumentA: value, argumentB: multiple words)": "org.swift.docc.Directive.MissingExpectedCharacter", | ||
| // Duplicate argument | ||
| "@Directive(argumentA: value, argumentA: value)": "org.swift.docc.Directive.DuplicateArgument", | ||
| ]) | ||
| func testEmitsWarningsForInvalidMarkup(invalidMarkup: String, expectedDiagnosticID: String) throws { | ||
| let document = Document(parsing: invalidMarkup, options: .parseBlockDirectives) | ||
| var problems = [Problem]() | ||
| _ = (document.child(at: 0) as? BlockDirective)?.arguments(problems: &problems) | ||
| return problems.map(\.diagnostic) | ||
|
|
||
| let diagnostic = try #require(problems.first?.diagnostic) | ||
|
|
||
| #expect(diagnostic.identifier == expectedDiagnosticID) | ||
| #expect(diagnostic.severity == .warning) | ||
| } | ||
| } |
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.
Maybe make this stronger? I wasn't sure how heavily you wanted to lean into swift-testing.
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'm not sure what amount of assertiveness (if that's the correct word) is right for this messaging. That's precisely what I hoped to get feedback on in this PR.
The team has previously talked about using Swift Testing for new tests and to slowly and incrementally transition existing tests.