Skip to content

Propagate method async-ness during test discovery #258

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

Merged
merged 5 commits into from
Nov 10, 2021

Conversation

briancroom
Copy link
Contributor

Extend IndexStore.TestCaseClass to include information about async test methods.

This adopts the indexer enhancement from swiftlang/llvm-project#3452

This should be reviewed with a corresponding SwiftPM change, to be posted, which is also where a test is included.

@neonichu
Copy link
Contributor

neonichu commented Nov 9, 2021

@swift-ci please test

public var name: String
public var module: String
public var methods: [String]
public var testMethods: [TestMethod]
@available(*, deprecated, message: "use testMethods instead") public var methods: [String]
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not too sure what the source compatibility requirement on this is. Let me know if this should be different!

@@ -14,9 +14,24 @@ import TSCBasic
public final class IndexStore {

public struct TestCaseClass {
public enum TestMethod: Hashable, Comparable {

Choose a reason for hiding this comment

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

Would it be more flexible as a struct instead of an enum? Basically

public struct TestMethod: Hashable, Comparable {
    var name: String
    var isAsync: Bool
}

The way it is currently i feel like ties its basic modeling to this async-or-not distinction, but that’s really just one detail about a test method, and I wonder if it would be more future-proof to allow it to have stored state. I bring it up in part because this type is public, thereby raising the importance of modeling it well since it may be harder to change since it’s exported outside its module.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree that this looks cleaner as a struct.


func add(klass: String, method: String) {
func add(klass: String, method: TestCaseClass.TestMethod) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Nitpick: klass: String -> classNamed className: String?

public let name: String
public let isAsync: Bool

public static func < (lhs: IndexStore.TestCaseClass.TestMethod, rhs: IndexStore.TestCaseClass.TestMethod) -> Bool {
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you need full Comparable or just Equatable? Equatable should be fully synthesized.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Lower down, we sort these, so I think we do actually need Comparable.

@briancroom
Copy link
Contributor Author

@swift-ci please test

@briancroom
Copy link
Contributor Author

Thanks for the feedback!

@briancroom briancroom merged commit 866b28a into main Nov 10, 2021
@briancroom briancroom deleted the bcroom/async-tests branch November 10, 2021 02:09
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.

4 participants