テスト

ソフトウェアの私のキャリアを通じて、私は、さまざまな態度や意見をテストコードに向かって来ている.二つの極端は、「何かが複雑すぎるので、テストが書く価値がない」ということです、あるいは、チェックされているすべての1つのコードは、テスト'を伴うべきです.これら2つの対照的な意見のうち、後者は、常にそのような極端な形ではないが、はるかに普及している.ここでは、コードをテストする必要が必ずしもないという3つのケースを議論します.コードの明白な正しさの部分は、冗長結合テストはリファクタリング時に経験することができますそしてビジネスの重要なコードのしばしばimmutability.その代わりに、私たちは、何かを実行する前に、本当にテストが必要であるところを考慮しなければならないと思います.

明白

チュートリアルを見たり、コースを見たり、単体テストの本を読んだことがあるなら、次の行に沿ってコードをテストする例を見てみてください.

func Sum(x int, y int) int {
    return x + y;
}

間違いなく、あなたはそれを確実にするためにいろいろな入力をチェックするテストを書く方法を正確に示すでしょうSum 関数はあなたが考えることができるすべての可能な場合のために正しい結果を生成します.
しかし、これらのチュートリアルがすべてを検討するのに失敗したのは、関数が最初にテストを必要とするかどうかです.上記の例を見れば、それが何を主張しているのではない可能性があると思いますか?簡単な方法で表現できますか?あなたの頭を包むのは難しいですか?これらの質問のすべての3つの答えは(希望)です.これはどのようにコードを直感的に一目で、広範な証拠やテストを必要とせずに修正することができます示しています.非常に有力なコンピュータ科学者のトニー・ホア卿は、悪名高い以下のように言った.

“There are two ways of constructing a piece of software: One is to make it so simple that there are obviously no
errors, and the other is to make it so complicated that there are no obvious errors.”

レトリックのこの部分は、我々が尋ねた質問と完全に収まりますSum 例.実際には、何かが「明白なエラーがないほど複雑である」とき、テストが本当に必要であるのを見ることができます.これらのテストは、これらの明白でないエラーが存在しないことを示すことによって値を証明するでしょう.だから、単純に、'明らかに'正しいコードは、テストを追加する必要がありますか?代わりに、テストを追加する前に質問をする必要があります.この質問に対する答えがイエスであるならば、何が明白であるかについてテストする必要はありません.

結合した

システム(単位/サービス/UI/統合/終わり-終わり、またはいろいろな他の名前)のために書くどんなレベルのテストに関して決定するとき'Testing Pyramid' すぐに心に湧きます.あなたが前に考えを見ていないならば、我々が個々の「単位」レベルで我々のテストの大多数をするということを示唆してください、テストのこの単位レベルの結果は速く走ることができて、速くて、安くて、効率的にコードカバレッジの高いレベルを提供することができます.それから、我々はより高いレベルのテストを非常にスパーパーな方法で提供しなければなりません.

このシステムは簡単で、最初は完全に意味をなす.通説もある.しかし、コードの使い捨て可能性やリファクタリングの能力は、どのようなテストを書くか、どのように書くかにおいて重要な考慮事項である可能性があります.連続した仕事をしているどんなシステムも、単位を見ます、あるいは、コードの孤立した部分は現れて、消えて、時間とともに完全に異なる形をとります.これは、自然の進歩と進化の作業、生活ソフトウェアです.この点を強調するために、私は'既存の単位テストが完全に無関係であるか冗長であるとわかるために、あなたがcodebaseのセクションをリファクタリングしたことがありますか?もしそうならば、これは最初のテストがコードのレイアウトと構造に過度に連結されたことを示します.テストが単にあなたが書いた最初のコードに一致するより多くのコードであることを覚えていてください(あるいは、TDDを実行するならば、彼らは単にあなたが書くことになっているコードに同意するコードです).
構造の急速かつ絶えず変化しているコードの領域では、システムのより高いレベルの作業が典型的により安定であるので、より高いレベルのテストは、保守性と安定性のより大きなレベルを提供する.これらのテストは、かなり完全に冗長にされる可能性が低い.

しかし、これは興味深い難問を示します:コードが将来構造またはアプローチで変わるかもしれないとき、我々はどのように知っていますか?我々が時間の前にこれらの地域を特定することができたならば、我々の新しく発見された前科学は単に我々が最初により良い形で彼らを書くことを意味することができました.悲しいことに、しかし、我々は暗闇の中で手探りで残っています:コードを組織化する試みは、知識の現在の状態を与えられる「最善の努力」アプローチです.
しかしながら、私たちは、システムが長く存在しているのを理解しています.これは、テストが完全に適切であることについての情報を決定することができます.若いシステム、または不確実性の高いシステムは、高レベルのブラックボックスのスタイルのテストから、これらの最も時間の経過とともに構造的変化を受ける可能性が最も高いです.これらのテストは冗長性を危険にさらす可能性が非常に少ない.対照的に古い、より安定した、またはよりよく理解されたシステムは、単位テストが提供することができる柔軟性と効率的な報道からより利益を得ます.
全体的に、システムの年齢、安定性と不確実性は、我々が書くどんなテストを下支えする必要があります.しかし、私たちは、コードとその進化を理解することで、これを補う必要がありますまたは'これらのXヶ月/年の時間に関係がない可能性が高いですか?

不動産業者

私が取り組んだ大規模なソフトウェアプロジェクトの多くでは、むしろ興味深いアイロニーが存在しています.コードの最も重要な、ビジネスの重要な部分は、しばしば最も不十分にテストされます.それらの出力は明確な定義を欠いているし、一見小さな変化が災いを招くかもしれない.しかし、彼らはこのように残っている.

数年前、私はNHSプロジェクトで働いた.これは、非常に複雑かつ基本的なシステムを病院の治療と価格を関連付けると、これらの価格に基づいてレポートを生成する責任を負い過ぎていた.レポートシステムは、テストの何千もの細心の注意を払って入力の大規模な様々なすべての可能な出力をチェックしてテストされました.これらにもかかわらず、プロジェクトのコアシステムは、ほぼ完全にテストに欠けていた.それは本当にレポートをテストする副作用としてテストされました.コードは信じられないほど動作するように、テストに耐えることがなかったので、それはなかった.その時、私はそれがシステムのそのような基本的な部分であったとき、それがどのようにそのように残されることができたかについて、理解しませんでした.
私は、後に、理論的根拠が信じられないほど単純であるとわかりました.オリジナルのコードの概念の証明書として書かれた.その結果、生産コードとなった.誰も信じられないほど難しいと追跡し、修正する高価な可能性が未知の回帰を引き起こすの恐怖のための変更をしたいと思った.同様に、価格を割り当てるためのプロセスは固定的な論理であった.それは時間とともに変化しておらず、新しい要件はどのように機能しているのかを変更しなかった.このような重要なコードのコードであっても、テストをしていないというコストは、コードを変更してテストする努力をして、それをテストするための努力によって、非常に重みを増しました.
私はここで重要なビジネスシステムをテストしないと主張していますか?いいえ-全くではない!しかし、我々が完全な世界に住んでいないと認めることは、重要です.重要な部分のためのシステムの不足しているテストは至る所に存在して、私が認めたいよりはるかに一般的です.しかし、これは私がそれがそうであったと思う悲惨な若い私でありません.コードの断片が複雑であるならば、それは働きます、そして、決して変わりません、そして、それがそれが悪いテストであるならば、それは重要ですか?しかし、変更を加えるとき、テストを加えることはまだ慎重であるでしょう-しかし、我々はまだ質問をすることができます.それは尋ねる危険な質問です、そして、答えはほとんど排他的に'はい-テストを加えます.しかし、多分、時々、それは考慮する価値があるものです.

終わる

プロジェクトのライフサイクルを通して継続的な価値を提供する、うまく設計されたテストスイートを作成する方法は、難しい仕事です.「テストピラミッド」アプローチの支持者は、問題を過小評価します.意図が良い間、それはソフトウェア開発の絶え間なく変化する世界の実用性に根付くことができません:時間の上のコードの進化は簡単にテストを冗長であるか不必要にすることができます、そして、時々、それらのテストはリファクタリングへの障壁でさえありえます.「明白な」自然のきれいなコードも所有することができます.同様に、既存のコードが正しいことで、不変であるか、非常にまれに変化することに関して、単純な費用便益分析を考慮すべきです.すべてのテストは書く価値がある.すべてがテストされる必要がありません、そして、それはすばらしいです.