Skip to content

[SR-1417] Add non-optional overloads of XCTAssertEqual and XCTAssertN… #110

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

Closed
wants to merge 35 commits into from
Closed

Conversation

nsalmoria
Copy link
Contributor

…otEqual

Previously, the only version of the functions that accepted values was the one that implicitly wraps them into Optionals. This generated a confusing error message when the assert failed. Having a separate overload that accepts non-optional types ensures that the correct description is printed when the assert fails.

Example:
XCTAssertEqual(1, 2, "message", file: "test.swift")

Previous error:
XCTAssertEqual failed: ("Optional(1)") is not equal to ("Optional(2)") - message

New error:
XCTAssertEqual failed: ("1") is not equal to ("2") - message

bryanpkc and others added 6 commits May 11, 2016 14:21
…otEqual

Previously, the only version of the functions that accepted values was the one that implicitly wraps them into Optionals. This generated a confusing error message when the assert failed. Having a separate overload that accepts non-optional types ensures that the correct description is printed when the assert fails.
Enhance xctest_checker such that it substitutes the string "[[@line]]"
and "[[@line+<offset>]]" with the current line number of the source file
when performing checks.

This allows us to add and remove arbitary lines in the functional test
suite without manually updating line numbers in most cases. Line
offsets will still need to be updated when the distance between the
CHECK and the test failure changes.

To test the offsets out, use them in one of the asynchronous tests.
@modocache
Copy link
Contributor

Awesome, thanks for trying your hand at SR-1417, @nsalmoria! 💯

It looks like Apple XCTest's SDK overlay doesn't have overloads of XCTAssertEqual for optionals. To add these overloads to swift-corelibs-xctest, we'd need to add them to Apple XCTest as well. In fact, Apple XCTest has exactly the problem you describe in SR-1417:

// Using Apple XCTest (Xcode 7.3.1), this produces the output:
// "XCTAssertEqual failed: ("Optional(1)") is not equal to ("Optional(2)") - "
XCTAssertEqual(1, 2)

Could you try adding these overloads, as well as tests for them, to the Apple XCTest SDK overlay in the apple/swift repository? You can add a test to the existing tests here.

Sorry for the additional work. The good news is that you can improve this output for all users of XCTest, even users of Apple XCTest on OS X! 😍

@modocache
Copy link
Contributor

(Oh, and let me know if you'd rather not deal with building/testing the Swift project. If you'd like, I can take care of adding these overloads to Apple XCTest.)

briancroom and others added 3 commits May 15, 2016 23:42
[Tests] Automatically substitute [[@line]] numbers
Use the line number offsets introduces in #112
to make the functional test suite assertions less brittle. Now
contributors may add and remove arbitary lines in the functional test suite
without manually updating line numbers in most cases. Line offsets will still
need to be updated when the distance between the CHECK and the test failure
changes.
Extract some stuff to separate files
@nsalmoria
Copy link
Contributor Author

As it happens, I am a user of XCTest on OS X :-) I'll take a stab at it.

[Tests] Use line number offsets for assertions
@modocache
Copy link
Contributor

Excellent! Please tag @modocache when you send a pull request. :)

nsalmoria and others added 3 commits May 16, 2016 22:39
…otEqual

Previously, the only version of the functions that accepted values was the one that implicitly wraps them into Optionals. This generated a confusing error message when the assert failed. Having a separate overload that accepts non-optional types ensures that the correct description is printed when the assert fails.
Add an option to specify the install prefix for CoreFoundation depend…
ddunbar and others added 12 commits May 24, 2016 08:37
 - This is useful in clients which would like to use Swift type inference to
   define the `allTests` array. If none of the tests in the class throw, Swift
   will infer the type of that array as `(String, (T) -> () -> ())` which is not
   convertible to the type expected by the `testCase` method.

 - Resolves: https://bugs.swift.org/browse/SR-1589
[SR-1589] Add non-throwing testCase() wrapper function.
This includes updating the documentation to indicate that this is the
preferred way of declaring `allTests` for users of the library.
Take advantage of type inference when specifying `allTests` variables.
swiftlang/swift#2609 introduced a change to
the default behavior of the Swift driver, which now uses the gold
linker unless specified otherwise. This caused a linker error in
swift-corelibs-xctest's test suite, which this commit fixes.
[Tests] Set LD_LIBRARY_PATH when running tests
 - This allows XCTest to find Foundation adjacent to itself, and fixes runtime
   linker problems when using Gold, which automatically uses DT_RUNPATH instead
   of DT_RPATH and so no longer inherits the search path into the Swift runtime
   libraries location used at build time on the client (which `swiftc` currently
   automatically injects).

 - Fixes SR-1631.
@modocache
Copy link
Contributor

This is blocked by swiftlang/swift#2788. @mike-ferris-apple, you're probably busy with WWDC, but could you take a look at that pull request?

Once swiftlang/swift#2788 is merged we can ask @nsalmoria to rebase these changes, then I'll review and merge them.

@modocache
Copy link
Contributor

@nsalmoria Sorry for the delay! Now that swiftlang/swift#2788 is merged, can you rebase these changes? The conflict is probably due to #122, which moved these files around. Sorry!

Let me know if you're not sure how to rebase or would like some help.

nsalmoria added 3 commits June 8, 2016 20:59
…otEqual

Previously, the only version of the functions that accepted values was the one that implicitly wraps them into Optionals. This generated a confusing error message when the assert failed. Having a separate overload that accepts non-optional types ensures that the correct description is printed when the assert fails.
…otEqual

Previously, the only version of the functions that accepted values was the one that implicitly wraps them into Optionals. This generated a confusing error message when the assert failed. Having a separate overload that accepts non-optional types ensures that the correct description is printed when the assert fails.
@nsalmoria
Copy link
Contributor Author

@modocache I think I have rebased? Not sure if I was supposed to do things differently to avoid pulling in all the history from master :-/

@nsalmoria
Copy link
Contributor Author

@modocache I created a new pull request #123 from a new branch to attempt fixing this mess. Closing this one.

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.

6 participants