Apologies if this is covered somewhere else already but after a look around I couldn't see anything so thought I'd post in here!
Looking at the various assertions I'm curious what the thinking was to move from the named assertions we got in XCTest like XCTAssertEqual(x, y) to the now open assertion which expects a bool (in this case the equivalent would now be #expect(x == y))
It seems like the new open macro looks quite nice but is a little impractical and can possibly lead to typos if you don't use the right amount of equals signs. It also doesn't read as nicely IMO.
I could be being a dinosaur here though and too used to XCTest so I'm just a little curious to know what the thinking was when designing those new assertions
Thanks for the question! My colleague @smontgomery wrote about this design decision in the package's vision document.
To quote:
Offering a large number of specialized expectation APIs is a common practice among existing libraries: XCTest has 40+ APIs in its XCTAssert family; JUnit has several dozen; RSpec has a large DSL of test matchers.
Although this approach allows straightforward reporting, it is not scalable:
It increases the learning curve for new users by requiring them to learn many new APIs and remember to use the correct one in each circumstance, or risk having unclear test results.
More complex use cases may not be supported—for example, if there is no expectation API for testing that a Sequence starts with some prefix using starts(with:), the user may need a workaround such as adding a custom comment which includes the sequence for the results to be actionable.
It requires testing library maintainers add bespoke APIs supporting many use cases which creates a maintenance burden.
Depending on the exact function signatures, it may require additional overloads that complicate type checking.
We believe expectations should strive to be as simple as possible and involve few distinct APIs, but be powerful enough to include detailed results for every expression. Instead of offering a large number of specialized expectation APIs, the APIs should be general and rely on built-in language operators and APIs to cover all use cases.