Skip to content

Allow selecting a particular test or test case to run from the command line #64

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 2 commits into from
Mar 14, 2016

Conversation

briancroom
Copy link
Contributor

This adds the ability for test binaries using XCTMain to receive a command-line argument that specifies that only an individual test or test case should be run, as implied in this proposal:

./FooTests FooTestCase/testFoo  # Run a single test method
./FooTests FooTestCase          # Run all the tests in FooTestCase

See also swiftlang/swift-package-manager#168 which begins implementing this in swift test.

@czechboy0
Copy link
Member

👍
What if the passed-in TestCase/Test doesn't match any existing test? I can't find anything that would warn/error out, so users might accidentally filter out all tests (test nothing), but still get a "success" return code. Or is it ensured elsewhere that at least one test runs?

@briancroom
Copy link
Contributor Author

@czechboy0 nope, you are correct that it would run 0 tests and exit with a 0 status code. I was copying the behavior of the xctest runner app on OS X because that's what swift test would call into there, although I agree that is potentially misleading and a different behavior may be desirable.

@mike-ferris
Copy link

Very cool. The test you added for this might be expanded to run a third time with no argument to ensure that the default behavior is intact, running all the tests.

@briancroom
Copy link
Contributor Author

Yeah I considered that, but figured that there were plenty of other funcional tests that thoroughly cover that case. Still, having the contrast present in the one test file could be nice.

@briancroom
Copy link
Contributor Author

Added it now 😀

// CHECK: Test Case 'SkippedTestCase.test_baz' started.
// CHECK: Test Case 'SkippedTestCase.test_baz' passed \(\d+\.\d+ seconds\).
// CHECK: Executed 1 test, with 0 failures \(0 unexpected\) in \d+\.\d+ \(\d+\.\d+\) seconds
// CHECK: Total executed 3 tests, with 0 failures \(0 unexpected\) in \d+\.\d+ \(\d+\.\d+\) seconds
Copy link
Contributor

Choose a reason for hiding this comment

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

I've been thoroughly convinced by your suggestions in #43, and I think you should place these assertions as close to the source code they're testing as possible (like this: modocache@22f1d24#diff-38abae29a59be553f8b7fc357a30e6ecR14). In fact, I think we should modify all of our tests in this style (but in another PR)!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For this test in particular, I don't think it's going to work to reorganize the CHECK lines, unfortunately, because of the way that this one executes the tests repeatedly in order to compare the output when running them with different test filters active.

Or is there a neat way to structure this that I haven't thought of yet?

Copy link
Contributor

Choose a reason for hiding this comment

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

See my other comment: you may be able to use a distinct check prefix for each of the three runs.

@modocache
Copy link
Contributor

Wow, you make it look easy! Brilliant.

@briancroom briancroom force-pushed the select-test branch 2 times, most recently from 4283e9f to 3423b86 Compare March 8, 2016 04:04
@briancroom
Copy link
Contributor Author

Updated and squashed!

The reordered assertions worked out really well @modocache, thanks for pointing out this feature of the test infrastructure!

@briancroom briancroom force-pushed the select-test branch 2 times, most recently from f7e536a to e38575b Compare March 10, 2016 21:16
@briancroom
Copy link
Contributor Author

This is ready to go as far as I am concerned. I'm not sure if there's any point in asking CI to do anything with it right now?

@modocache
Copy link
Contributor

I'm under the impression that CI is mostly broken right now due to the Swift 3 migration, yeah. @mike-ferris-apple, could you ask @swift-ci to please test, just to see what happens?

Also, @mike-ferris-apple, how would you feel if I tested this using the CI presets locally, then merged? Just like the good old days before @swift-ci was enabled for this repository! 😂

@modocache
Copy link
Contributor

CI issues aside, I agree that this is ready to be merged anytime!

@mike-ferris
Copy link

@swift-ci please test

@mike-ferris
Copy link

I'd be OK with merging this hand-tested since the CI seems to be in a bit of a state right now.

@modocache
Copy link
Contributor

Great. I'll merge this and #68 sometime today.

@modocache
Copy link
Contributor

Sorry for the slow turnaround, @briancroom. I tried running the tests on Linux but encountered the following failure, which is probably due to the Swift 3 migration:

/home/modocache/GitHub/apple/swift-corelibs-xctest/Sources/XCTest/TestFiltering.swift:63:54: error: 'split(_:maxSplit:allowEmptySlices:)' is unavailable: Please use split(separator:maxSplits:omittingEmptySubsequences:) instead
        let components = selectedTestName.characters.split("/").map(String.init)
                                                     ^~~~~
Swift.Collection:3:17: note: 'split(_:maxSplit:allowEmptySlices:)' has been explicitly marked unavailable here
    public func split(separator: Self.Iterator.Element, maxSplit: Int = default, allowEmptySlices: Bool = default) -> [Self.SubSequence]
                ^

The following change got all the tests passing for me:

diff --git a/Sources/XCTest/TestFiltering.swift b/Sources/XCTest/TestFiltering.swift
index f67d3a1..78e5191 100644
--- a/Sources/XCTest/TestFiltering.swift
+++ b/Sources/XCTest/TestFiltering.swift
@@ -60,7 +60,7 @@ private struct SelectedTest {

 private extension SelectedTest {
     init?(selectedTestName: String) {
-        let components = selectedTestName.characters.split("/").map(String.init)
+        let components = selectedTestName.characters.split(separator: "/").map(String.init)
         switch components.count {
         case 1:
             testCaseName = components[0]

On OS X, I needed to fix a build error in Foundation (swiftlang/swift-corelibs-foundation#284) in addition to applying the above change, but the tests all pass!

Ping me once you've made the above change and I'll merge--thanks!

@briancroom
Copy link
Contributor Author

I for one welcome our new Swift 3 overlords..and am regretting not investing the time in building an updated toolchain earlier.

Regardless, I've made the change now!

modocache added a commit that referenced this pull request Mar 14, 2016
Allow selecting a particular test or test case to run from the command line
@modocache modocache merged commit 541d91d into swiftlang:master Mar 14, 2016
@modocache
Copy link
Contributor

Great! Thanks, @briancroom 💯

@briancroom briancroom deleted the select-test branch March 16, 2016 02:47
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