XCTAssertNotNil cannot handle optionals

[flashspys]

In your tests you are checking at various locations optionals not to be nil by passing them to the XCTAssertNotNil function. Unfortunally the function is unable to process Swift optionals and will threat even nil-optionals as not-nil. For this reason #187 is crashing and not failing, because first the optional is checked and then force-unwrapped. Another option to check optionals to be nil should be considered, for example as mentioned in this blogpost.

[flashspys]

Another option would be to add SwifterSwift's very first XCTest extension 😆

XCTest.assertOptionalNotNil

[SD10]

@flashspys Thanks for pointing this out. I think we could also set XCTest to stop testing after failing once. The downside to that is we don't know of any failed tests after this until the next run, but I think it could be a fair compromise.

[flashspys]

This will not solve the situation in that a single test is crashing ( != failing) because some force-unwrap fails.

[SD10]

@flashspys let me make sure I understand correctly, are you saying this test won't fail:

let nilValue: Int? = nil
XCTAssertNotNil(nilValue)

[flashspys]

I thought, but no. The behaviour is more complicated. I think the following pictures will help to understand:

In this case, XCTAssertNotNil will fail as expected.

But in this case XCTAssertNotNil will not detect the nilness of string. The test will crash at the force-unwrap

Whyever...

[SD10]

@flashspys Ok, I think we're on the same page. That is why I was suggesting this:

  override func setUp() {
    continueAfterFailure = false
  }

If XCTAssertNotNil fails the proceeding code won't be executed.

😅 Actually, I see what you mean now.
So XCTAssertNotNil will not fail in the case where it has more checks after it?

[flashspys]

I think it is more an UI Bug than I thought because your idea is right. It will fix it and even in the second example it will stop executing after XCTAssertNotNil when you add continueAfterFailure = false

My guess is that Xcode is just not displaying these small red x in case of a runtime error.

And now I understand your idea from your first answer. I'm happy to announce that we don't even need to make a compromise. You can stop a single test after fail without stop the other tests.

[SD10]

@flashspys Yeah the method I showed above would work. What's happening is there is no test report being shown due to the crash. XCTAssertNotNil is still detecting the nilness of the String.

Feel free to open a Pull Request making these changes to the tests where we use XCTAssertNotNil. In general, this is a solid example as to why we should stop using force unwrapping even in tests.

[omaralbeik]

Fixed in v3.1.0