はじめに
まあ私も咳さんから学んだのですけどね! https://t.co/O1NtxxMB2a pic.twitter.com/wUCCU0dT1X
— Takuto Wada (@t_wada) 2024年10月26日
という古くから伝わる名言に関して、個人的にもかなり「なるほど」という学びがあり、頭が整理されたきっかけになった記憶があります。
ただ、この名言がうっかりすると全然違う結論を導くために使われうるなぁという危うさを感じていて、久しぶりにツイッター(X)で目にしたタイミングでふと思い出したので、その気持ちを記しておきたい所存です。
どこに危うさを感じているのか
まず気になるのはこれ。
- (A) この言説が品質テストをdisるために誤用されてはいないか
あと、ふわっと気になるのは、以下の2点です。
- (B) テストで見つかった問題に対してどう対処(=プログラミング)するのかが重要だという話がわかっているのか
- (C) テスト前の実装作業(=プログラミング)においてどうやってるのかが死ぬほど重要だという話がわかっているのか
個人的な解釈
元の発言の正しいお気持ちは直接伺ったことはないのでわかりませんが、個人的には次のように理解しています。
- テストとは実装された振る舞いを観測をしつつ、期待される挙動との差分がないかをチェックすることなので、いくらどのような観測をしたところで、対象物が改善されることはない
- テストという観測手段によって、期待とは異なる挙動が見つかった時に、それを修正する作業(=プログラミング)を通して、対象は改善される
- (さらに追加するとすれば) 元々の実装作業として、適切なスキルを持った人が実装しているか、だったり、よりよいプラクティスを導入しているか、だったり、実装(=プログラミング)上の頑張りによってテストで観測されても問題が見つからないように品質をあらかじめ確保しておくのが重要である
それを踏まえた上での解釈上の危うさ
(A) この言説が品質テストをdisるために誤用されてはいないか
「チェックのためにテストは当然必要なんだけど、品質を上げる作業自体はプログラミングにあるんよ?」という話のはずが、「品質を上げるためにプログラミングを頑張ればテストなんて不要になるんや」と誤解されてないですよね、という話です。
これは単純に国語的な読解力に対する懸念です。
「いや、そんな解釈をする人なんて普通いないでしょ」と思いたいところですが、最近ではそういう解釈も個人ごとに色々多様性がある世の中ですし、あまり楽観的にはいられないのでは...という懸念がある、という心配性おじさんの妄想なのですが、いや意外と危うい気がしているので書いておきたいなぁ、というそういう気持ちです。 完璧に理解されているみなさまは生暖かくスルーしていただいていいんですよ...。
(B) テストで見つかった問題に対してどう対処(=プログラミング)するのかが重要だという話がわかっているのか
たとえば、見つかったバグに対してその場しのぎのワークアラウンドコードを仕込むことで指摘された事象自体は改善されたように見えるかもしれません。 しかし、そのコードがたとえば「ひどい変数/関数名を使っている」「概念上無関係な関数に意図のわかりづらいコードを追加している」とかの問題を孕んでいると、最終的なソースコードとしての品質が上がったのか?という点でかなり疑問がある結果になってしまいます。 そのバグは修正されたかもしれないけど、コードの可読性が低下して(品質的な用語でいえば)保守性が低下してしまった、という見方もありえます。
つまり、テストで発見された品質上の問題を解消するための修正作業(=プログラミング)で下手を打ったら、それは品質が向上したとは言い難い別の世界線に遷移してるだけという可能性もある、という話ですね。
(C) テスト前の実装作業(=プログラミング)においてどうやってるのかが死ぬほど重要だという話がわかっているのか
これについては、本質的にはもっとも重要な話で、基本的にこのレベルで成果物の最終的な品質が決まる、という風に個人的には思ってますが、じゃあ何をすればそこがいい感じになるのか、というのは観点が多岐に渡るので、今回はスルーします。
おわりに
というわけで、テストでは直接品質はあがらないのですが、テストで問題を見つけることで品質を上げるための修正(=プログラミング)をするチャンスは生まれますし、そこで品質を上げることができるかはその修正(=プログラミング)の内容による、という話でありつつ、そもそもテスト以前の実装フェーズでのプログラミングで品質を上げるというのが実は一番重要なんですよね、という構造になっているというその辺りの気持ちが伝わればうれしいです。
補足
元のTwitter(X)の議論は「テストコードの存在が直接品質を担保しているわけではないので、テストコードがたくさんある=品質を向上させている、ではない」「バグの検出に役立たない冗長なテストコードはむしろ害悪」という話だと思っていて、今回の記事はそこは全然否定していないというか、全面的に同意です。