f82be27666 flipped around calls to `selectPendingCount(_:)` so that it
respected the new async nature of the method; however, it neglected to
add enough XCTestExpectations to keep the test methods running through
the callbacks. Add those here.
It looks like two tests in FeedlySetStarredArticlesOperationTests
created but never referenced XCTestExpectation instances. Based on the
other nearby tests, add a call to `fulfill()` inside the associated
completion block after the rest of our test assertions are done.
There was one call to a throwing function inside
`checkArticles(in:correspondToStreamItemsIn:)` which was not
appropriately marked with `try`. Add that keyword, and then bubble out
the chain of errors through additional layers of helpers to the
enclosing test:
* This `checkArticles` variant was called by two others
* …one of which was used in `testAddNewFeedSuccess()`
* …another of which was used in various `verify` sync helpers
* …which were referenced from `testSyncing()`, a test case method
None of these involved any particular async hoops to jump through, and
since the top-level callers were all test functions, we can count on
XCTest to handle any errors thrown — no additional `catch` or handling
on our part is necessary.
Two more cases of completion blocks taking Results, requiring a
do/catch/Result.get() to unwrap.
This commit deliberately leaves one build error for a more comprehensive
fix, since it occurs in a helper function that will have broader
fallout.
Most fetch completion blocks took a parameter that was expected to be
some result data type, but is now a Result. Rename these parameters;
wrap their existing bodies in do/catch blocks; and recreate the original
underlying variable using the result of `Result.get()`.
Prepend a few synchronous calls that started throwing with `try` along
the way.
Add `error` parameters to completion blocks which now pass them. Assert
these errors are always nil in the existing tests.
Flip calls to `selectPendingCount()` so they are async, with a
completion block that asserts about the results instead of asserting
about the return value. Since the closure takes a Result, unwrap it in a
do/catch block at each site; `XCTAssertNoThrow` doesn't help us bubble a
value out from `Result.get()`, and I'd rather not use `try!` here. There
might be a stylistic discussion to be had about this unwrapping, though.
Brent Simmons
Kiel Gillard
Tim Ekl
Maurice Parker