過度なDRYは読みやすさの敵！？「リーダブルテストコード」という発表をしました #vstat - give IT a try

先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「

[saiyu99sp]

そもそもクラス図やシーケンス図などで設計せずにコード書いてそう。 それは本当に重複なのかを考えるのも大切だと思う。

[NOV1975]

テストコードが勝手にコードに寄り添ったらダメよねってのは正しい。というか、テストコードはコストがかかるものだし、ここで言われるような観点でメンテナンスする気がなかったら意味がないんだよ。

[nilab]

「ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です」

[dorapon2000]

“仕様変更が発生すると大量のテストが失敗することもあります。ただ、それはデメリットではなく、仕様変更のインパクトがテストコードのおかげで可視化された、と好意的に捉えるようにしましょう。”

[sisya]

DRYすぎるという感覚はわかるのだが、例示された内容がWETすぎて実用性がなくなっているように感じた。例に突っ込んでも仕方ないのだが、税率の部分は税率そのものをチェックする定数仕様を定めるべきなのではと思う。

[qawsklp]

DRYよりも、可読性を上げるにはその言語になんの機能が足りないのか？とかを考えてしまうなぁ..

[pascal256]

後で読む

[sonots]

Yes, テストコードはベタ書きが正義

[hatest]

DRYにしない→湿ってる→べたべた→べた書き

[Watson]

テストコードをテストするものが必要になるんでな

[snailcat]

QAの悪いパターンの方は何をテストしたいんだこれ。税率計算結果が税率計算結果と同じなことを確認してたらおかしくない？リーダブルとかいう問題じゃない気がする

[soybeancucumber]

DRYによって読みやすさが損なわれるのはアーキテクチャーに問題があるだけでは。。。

[Guro]

テストコードをDRYで書くというのがそもそもよくわからんな（テストコードを書く環境でないけど）。仕様がかわったらテストもかわるじゃろし、そもそも何をテストしているのかわからんでテストを流すのが最近なのか。

[tattyu]

テストコードをDRYにするなって事で良いのかな。確かにテストコードの定数とかはその場に埋め込んだ方が見やすいかもね。というかそうしてたわ。

[Shinwiki]

甘やかす方向に理を与えるとPV稼ぎができる

[Sampo]

これはホントそうで、プロダクト側で用意した便利な道具は何も信用せずに同じものをテスト側で書かないとなのよね。Suicaシステムのテストのためにまったく同仕様の比較対象用システムを一個作った話は有名。

[shibainu1969]

「DRYってなに？」と思ったのでこれからググる。

[nishi1231chang]

原則を過度に守りすぎて、かえって保守性悪くしてるのあるあるだね。読みやすさや拡張性などを、保つと言う本来の目的を意識してないとなりやすい。

[surume000]

テストコードに定数使わないほうがいいという話なるほど

[yarumato]

“ベタ書きした方がバグを検知しやすい　テストが失敗してくれる。「ほどほどのDRY」は許容しても構いません。”

[motchang]

“仕様変更が発生すると大量のテストが失敗することもあります。ただ、それはデメリットではなく、仕様変更のインパクトがテストコードのおかげで可視化された、と好意的に捉えるようにしましょう。”