はじめに
テストのメソッド名ってどういうのがいいんだろう？と思って Poll してみました。これのお話です。
何番のテストがいいですか？（５番は断念🥲）
— am10 (@am103141592) June 19, 2021
テスト名候補
テスト対象は下記メソッドです。
|
1 2 3 |
func hoge(flag: Bool) -> Int { return flag ? 0 : 1 } |
テストの候補としてあげたのは下記５つ（５番は Poll 対象外）です。
１番
なにも考えずに「テスト対象＿条件＿期待値」という形式で書いてみました。（Assert みればいいんで期待値は別に入れなくていい気もしました。）
|
1 2 3 4 5 6 |
func testHogeWithFlagMethod_flagIsTrue_returns0() { XCTAssertEqual(hoge(flag: true), 0) } func testHogeWithFlagMethod_flagIsFalse_returns1() { XCTAssertEqual(hoge(flag: false), 1) } |
２番
１番の変化型でテスト対象＿条件（日本語）＿期待値（日本語）で書いてみました。
|
1 2 3 4 5 6 |
func testHogeWithFlagMethod_flagがtrueの場合_0を返すこと() { XCTAssertEqual(hoge(flag: true), 0) } func testHogeWithFlagMethod_flagがfalseの場合_1を返すこと() { XCTAssertEqual(hoge(flag: false), 1) } |
テストメソッド名に関してはとくにコード書いて呼び出すわけではないので日本語でも問題ないのでは？と思ったりします（呼び出す場合はコード書いてるときに全角と半角変換繰り返さないといけないのでちょっとめんどそう。。。）。
３番
条件ごとにメソッドを分けていたのを XCTContext で分けるようにしてみました。
|
1 2 3 4 5 6 7 8 |
func testHogeWithFlagMethod() { XCTContext.runActivity(named: "flagがtrueの場合") { _ in XCTAssertEqual(hoge(flag: true), 0) } XCTContext.runActivity(named: "flagがfalseの場合") { _ in XCTAssertEqual(hoge(flag: false), 1) } } |
XCTContext で分けると下記のようにテストレポートが構造化されて見やすくなります。
私はテストレポートをあまりみたことないですが CI とかで便利なのかも？
４番
もう Assert みればわかるだろ！という感じでまとめてみました。
|
1 2 3 4 |
func testHogeWithFlagMethod() { XCTAssertEqual(hoge(flag: true), 0) XCTAssertEqual(hoge(flag: false), 1) } |
５番
パラメタライズドテストのメリット解説(Swift)をみて面白いなと思って真似してみました。
Poll の上限が４つだったので今回はテストパターンも多くないので候補からはずしました（きっとテストパターンが多いときに力を発揮してくれるはず）。
|
1 2 3 4 5 6 7 8 9 |
func testHogeWithFlagMethod() { let testCases: [(line: UInt, flag: Bool, expect: Int)] = [ (#line, true, 0), (#line, false, 1) ] testCases.forEach { XCTAssertEqual(hoge(flag: $0.flag), $0.expect, line: $0.line) } } |
テスト失敗した場合は下記のように testCases のところにエラーが表示されます。
集計結果
結果はこんな感じでした（投票数は２３人）。
| テスト | 投票数 |
|---|---|
| １番 | ７人 |
| ２番 | ３人 |
| ３番 | ７人 |
| ４番 | ６人 |
どちらかと言うと１番と３番が人気？
個人的には２番の日本語で書くのはわかりやすいと思ったのですが、メソッド名を日本語にするのは受け入れられにくいかな？とも思うので折衷案の３番が好きです。
ちょっと考察
ありがたいことに下記のような意見をいただきました。
コード修正してテストが失敗した時に、次のことがストレス無く判断できれば良いと考えている。
・修正したコードに問題があるのか
・テストの期待値を修正すべきなのか
たしかに！テストコードをみるときっていつか？というとテストを失敗したときですね。
この観点でいくと今回のテスト対象が下記なのでテストが失敗したときにどちらを修正すべきかはパッとわからないですね。。。
|
1 2 3 |
func hoge(flag: Bool) -> Int { return flag ? 0 : 1 } |
テストとセットではじめてこのメソッドの動きがわかるようなつくりになってしまってます。
結論：メソッド名はちゃんとつけよう！
ちょっとサンプルが悪かった。。。
おわりに
テストを書くとしたら今回提示したどれでも問題ないと思いますが、わたしが書くとしたら３番で書こうかなと思います！
なによりも大事なことはテストを書くこと！
みなさんとりあえずプロジェクト作成時に下記にチェックをいれましょう！
コメント