ユニットテストに関するいくつかの質問

Question

ユニットテストに関する2つの質問。

1. 私はしばらくユニットテストを書いてきましたが、通常、私がすでに書いていたクラスをテストするためです。最近読んだ 記事（古い記事に気をつけてください）コードの作成を開始する前にユニットテストを作成する必要があると述べています。

   誰かが実際にこの方法論に従っていますか？紙の上では良い考えのように思えますが、実際にはそうですか？

2. あなたの方法が悪い/悪意のある入力をどのように処理するかを見るためにユニットテストを書くべきですか？明らかに、「ユーザー」入力を処理するために特に悪い/悪意のある入力を処理するかを確認するための関数に対するテストを書きたいと思うでしょうが、このタイプの入力を決して渡さない機能はどうですか？どの時点で線を引きますか？

Answer 1

クラスが呼ばれる前にユニットテストを作成する方法論 テスト駆動型開発 （TDD）、2000年代初頭にKent Beckによって普及しました。アイデアは、必要な機能を説明するテストを作成するということです。当初、このテストは失敗します。クラスを書くと、テストが通過します。テストをリファクタリングして、より目的の機能を追加し、クラスをリファクタリングしてこの新しいテストパスを作成します。クラスは、テストが通過するとすぐに目標を達成しました。もちろん、これはクラスを超えて拡大します。

どのタイプのテストを書くかについては、パブリックAPIまたはプライベートAPIをテストしているかどうかに依存します。パブリックAPIは、特にAPIのユーザーを完全に信頼していない場合、入力が十分に形成されることを確認するために、より広範なテストを書く必要があります。プライベートAPI（コードによってのみ呼び出される方法）は、おそらくこれらのテストなしで逃げることができます - 私はあなた自身の開発チームが彼らに悪いデータを渡さないことを信頼することができると疑うでしょう。

Answer 2

テスト駆動型開発 かなり広範なコンセプトです。基本的なアイデアは、ソフトウェアの要件を満たすために必要なコードのみを作成しようとしているということです。そのため、要件のテストを作成し、次にテストをパスするコードを作成します。

私は個人的にTDDを使用していませんが、私はそうする人を知っています。私の個人的な考えは、データベースやユーザーインターフェイスなど、よりアプリケーション駆動型の何かに取り組んでいる場合に非常に便利であるということです。しかし、よりアルゴリズムが多い（物理学モデルのような）何かのために、私はそれが私の思考の列を破り、邪魔になることを発見しました。

Answer 3

最初にユニットテストを書くことは非常に一般的な慣行です。大きな利点は、コードが合格するテストを作成するだけでなく、重要なもの、達成しようとしていること、そして何が起こらないようにしたいかを定義するテストを書くことです。それはあなたがあなたのデザインを肉付けするのに役立ちます。また、コーディングする前に、外部の利害関係者でスペックを吟味することができます。

書くべきテストに関しては、それはあなたが持っている時間に基づいて少し主観的です。私はそれが決して直面しないシナリオのためにクレイジーな審査コードをしません。とはいえ、「決して見ない」とコーディングする入力が驚くべきことです。したがって、より多くのテストの方が優れていますが、ある時点では間違いなくリターンが減少しています。

問題でコーディングしている言語。コンパイラの問題が少なくなり、バグを追跡するのが難しい場合があるため、動的言語ではより多くのテストが必要です（最初の入力問題からさらに伝播できるため）。少なくとも、これは私の意見です。

また、入力がどこから来ているかという違いも生じます。一般大衆は積極的に悪意を持っている（すなわちウェブ）と見なされるべきであり、従業員は無能であると想定されるべきであり、仲間のコーダー（そしてあなた自身！）は少なくとも不注意であると想定されるべきです。しかし、あなたがあなたの内側のサークルに近づくと、危険は低下します。

Answer 4

誰かが実際にこの方法論に従っていますか？

はい。

紙の上では良い考えのように思えますが、実際にはそうですか？

はい。

あなたの方法が悪い/悪意のある入力をどのように処理するかを見るためにユニットテストを書くべきですか？

はい。

このタイプの入力を決して渡さない機能はどうですか？どの時点で線を引きますか？

ソフトウェアから精神病に移行するとき。

必要に応じて、不可能な状況のテストを書くことができます。しかし、あなたはあなたの時間とあなたの雇用主が明らかな方法で無駄にしています。

のテストを書きます 定義されています ユースケース。以上です。

想像力に基づいてランダムなテストケースを作成しません。

仮に？ もしあれば 定義されています ユースケースは不完全ですか？バマー。公式、契約上の、パブリックインターフェイスのテストを作成します。

設計が不十分であり、与えられたインターフェイスが不完全な仕様、矛盾、セキュリティホールに悩まされていることに気付いた場合はどうなりますか？これはテストとは何の関係もありません。これは単なるプログラミングです。悪いデザインは悪いデザインです。

いくつかの悪意のあるソシオパスがあなたのコードを受け取り、定義された仕様を超える（またはそれ以外の場合は満たさない）方法でそれを使用した場合はどうなりますか？バマー。ソシオパスが勝ちます。彼らはあなたがテストしなかった不可能な状況にあなたのコードを置くことができました。とても賢いためにビールを買ってください。

Answer 5

テスト前とテスト後のテストとの間には、考え方に違いがあります。以前にテストを書くことはの形式です 設計, 、コードのインターフェイスを設計し、予想される動作を定義しているという点です。その後、テストに合格するコードを作成すると、デザインを検証します。そして、開発の終わりに、あなたはたまたま一連のテストをすでに導入しています！

テスト後、既存のコードが通過するテストの書き込みのtrapを避けるために注意する必要があります。これは別の焦点であり、テスト前のバージョンほどそれほど多くは得られません。

Answer 6

すでにたくさんの答えがありますが、質問番号2についてもう考えてみたいと思います。

「データ駆動型」という独立したコードを作成する場合、コードが「悪い」または「良い」入力をテストしているかどうかは関係ありません。重要なのは、両方をカバーする十分なデータセットがあることです。