Convert String/Predicate/ProcessInfo/RecurrenceRule tests to swift-testing #1357
Conversation
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please test |
| // These are not necessarily valid recurrence rule, they are constructed | ||
| // in a way to test all encoding paths | ||
| var recurrenceRule1 = Calendar.RecurrenceRule(calendar: .current, frequency: .daily) |
There was a problem hiding this comment.
If I recall correctly, this was meant to test that the current calendar is encoded as such. We don't have any custom logic in RecurrenceRule encoding to handle such cases so it's also okay to encode with other calendars. But it'd be nice to minimize the diff.
There was a problem hiding this comment.
Removing the usage of .current here is important because the .current calendar also implies things like the current TimeZone. Unlike XCTest tests, swift-testing tests run in parallel with each other, including other tests which may change the value of the current calendar/timezone/locale. Tests that use or change the current calendar/timezone/locale need to be serialized to ensure they don't run in parallel like I did with the tests relying on the CWD. I can go ahead and setup the infrastructure for that now (I planned to do that later when refactoring the FoundationInternationalization tests) but if there's no custom logic for the current calendar, to avoid that need for these tests it's likely simpler to just switch to a non-current calendar than switch to an asynchronous task run on an actor.
There was a problem hiding this comment.
I see! It's good with me then. We can also use GregorianCalendarRecurrenceRuleTests.gregorian, which is initialized only once.
| @@ -681,12 +689,12 @@ final class GregorianCalendarRecurrenceRuleTests: XCTestCase { | |||
| rule.matchingPolicy = .strict | |||
|
|
|||
| for _ in rule.recurrences(of: start) { | |||
| XCTFail("Recurrence rule is not expected to produce results") | |||
| Issue.record("Recurrence rule is not expected to produce results") | |||
There was a problem hiding this comment.
Would this automatically mark the test as failing?
There was a problem hiding this comment.
Yep, XCTFail and Issue.record are equivalent - both record an issue that will cause the test to be marked as failed and continue execution to the end of the test to allow for recording additional issues
Applies more patches from #908 to bring a handful more FoundationEssentials test suites to swift-testing (adjusting the patches to account for newly added and modified tests)