-
Notifications
You must be signed in to change notification settings - Fork 633
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
tests: improve tests that are supposed to throw #1430
Conversation
Motivation: The do { try someOperation() XCTFail("should throw") // easy to forget } catch error as SomethingError { XCTAssertEqual(.something, error as? SomethingError) } catch { XCTFail("wrong error") } pattern is not only very long, it's also very error prone. If you forget any of the XCTFails, you might not tests what it looks like XCTAssertThrowsError(try someOperation) { error in XCTAssertEqual(.something, error as? SomethingError) } is much safer and shorter. Modifcations: Do many of the above replaces. Result: Cleaner, shorter, and safer tests.
1ad61a0
to
27f7bdc
Compare
} catch ChannelError.alreadyClosed { | ||
return | ||
return // as well as already closed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any value in something like assertMaybeThrows
which validates the error if one is thrown but doesn't fail if no error is thrown? I think I've only seen one or two occurrences of this elsewhere here so probably not...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few but unfortunately our TestUtils.swift
doesn't really scale. It's always just available in one test module but we have lots of modules and like 5 different repos :|. So I now prefer to stick with plain XCTest whenever possible...
Motivation: The do { try someOperation() XCTFail("should throw") // easy to forget } catch error as SomethingError { XCTAssertEqual(.something, error as? SomethingError) } catch { XCTFail("wrong error") } pattern is not only very long, it's also very error prone. If you forget any of the XCTFails, you might not tests what it looks like XCTAssertThrowsError(try someOperation) { error in XCTAssertEqual(.something, error as? SomethingError) } is much safer and shorter. Modifcations: Do many of the above replaces. Result: Cleaner, shorter, and safer tests.
Motivation:
The
pattern is not only very long, it's also very error prone. If you forget
any of the XCTFails, you might not tests what it looks like
is much safer and shorter.
Modifcations:
Do many of the above replaces.
Result:
Cleaner, shorter, and safer tests.