# A New Approach to Testing in Swift

**URL:** <https://forums.swift.org/t/a-new-approach-to-testing-in-swift/67425>\
**Category:** Discussion\
**Tags:** testing, xctest, unit-testing, swift-testing\
**Created:** [September 21, 2023, 5:01pm UTC](https://forums.swift.org/t/a-new-approach-to-testing-in-swift/67425 "2023-09-21T17:01:38Z")\
**Posts on this page:** 1\
**Showing post:** 20

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [September 22, 2023, 1:24pm UTC](https://forums.swift.org/t/a-new-approach-to-testing-in-swift/67425/20 "2023-09-22T13:24:52Z")

</div>

This is really cool! Thanks to everyone who worked on it—I'm really looking forward to using it to replace XCTest, which is definitely showing its age when using it in Swift.

One thing that I wasn't able to glean from the documentation so far is what kind of capabilities will there be for customizing expectations, in the sense that other testing frameworks can have custom matchers? For example,

- If I write an `#expect` statement that compares two multi-line strings, I'd like the failure output to be a diff of the two strings.
- If I write an `#expect` statement that compares two [protobufs](https://github.com/apple/swift-protobuf), I'd like the failure output to be a bit more semantic (this field is missing, this field has the wrong value), and perhaps even be able to say "ignore this field but compare everything else".

Anyone can write a boolean function to do those comparisons but the desirable feature is being able to customize that to provide structured failure feedback. I'm really curious what your thoughts are about how that kind of functionality could fit into the `#expect(...)` syntax!

---

_[View the full topic](https://forums.swift.org/t/a-new-approach-to-testing-in-swift/67425)._