Swift Testingは採用するべきか
結論採用!
Swift Testingとは
Swift Testingとは、一言で表すのであれば、
WWDC 2024で発表され、Xcode 16から使えるようになった、XCTestではできなかった色々な表現を使ってTestを書けるFrameworkです。
ちなみに、UITestはSwift Testingには含まれておらず、Unit TestのためのFrameworkとなっております。
情報源
Swift Testingの公式からの情報源はとても豊富なので、いくつか紹介していきます。
1: GitHub
Swift TestingはOpen Sourceなのでコードを見ることができます。
2: Apple Documentation
Swift TestingのDocumentationはかなり手厚いです。
3: WWDC Videos
入門編の Meet Swift Testing
発展編の Go further with Swift Testing どちらもSwift TestingのメインコミッターであるAppleの開発者の方直々の手厚い説明が含まれています。Swift Testingの嬉しいポイント
Swift Testingに期待できることは以下の二つがあると思います。
- より読みやすい整理されたTest Code
- よりわかりやすいTest Feedback
Swift Testingによって、Testの表現の幅が広がりました。新しく追加された表現の中には、元々XCTestでも表現できたけど書き方が変わったようなものや、正直あっても嬉しくない, 使わなさそうな表現も色々ありますが、嬉しい、XCTestではできなかった表現も数多くあります。今回は個人的に嬉しい、使いそうな新表現をいくつか紹介します。
#expect Macro
XCTestでは、assertの書き方がXCTAssertOOという形で、比較方法に応じて別々のassert statementが用意されていました。それがSwift Testingでは #expectで統一されるので、assert statementがよりconciseでreadableになります。実際、XCTestでも全部XCTAssert()で書けば統一されたある程度conciseな状態で書けるわけですが、"せっかく準備してもらってるんだから、XCTAssertGreaterThanとか、XCTAssertNotEqualとか使いたいよね"という気持ちになって実際はちゃんと使い分けている開発者が世の中多いのではないかなと予想していて、僕もその一人です。その方が読みやすい派とXCTAssertで統一したい派で派閥はありそうですね。今後はそんな派閥争いも無くなります。
@Test(arguments:)
SwiftTestingでは@Test(arguments:)を使うことで配列をtest functionの外側に出すことができ、その上でそれぞれの配列のアイテムを元にそれぞれ独立したtest caseとしてparallelに実行できます。嬉しいですね。入れ子も浅くてみやすいですし、test code本体がconciseでreadableになる点もプラスです。
instanceがcase同士でshareされない
instanceがcaseを超えてシェアされないので、setup, teardownの記述も省略できてCode全体のVolumeが小さくなります。setupをinit, teardownをdeinitとして書くことも可能。
まとめ
Swift Testingを使うことでXCTestよりも簡潔で読みやすいTestを書くことが可能で、Testの保守性もあがって嬉しいですね。Xcode 16にアップデートして早速導入してみてはいかが。
この記事はVoicy アドベントカレンダーのうちの一つなので他の記事もチェックしてみてください。
Discussion