私たちの会社は、コードの品質を改善し、コードを提供する際に採用するプロセスを進めています。私の質問は単体テストに関するもので、機能の実装を求められたときに採用するプロセスに関する情報を収集したかったのです。
TDD は単体テストの形式ですか。TDDで私が理解していることから、最初にテストを作成し(失敗します)、コードを作成してから、合格するはずのテストを実行します。コードが外部メソッド呼び出しを行う可能性があります。しかし、最初にテストを作成するときに、必要なスタブ化についてどのように知る必要があるでしょうか?
以前のリリースでアプリケーションをビルドする場合、ビルドにどのような種類のテストを含めますか? ビルドは統合テストを実行しますか、それとも単体テストのみを実行しますか?
TDD とは別に、他の種類のテストを作成しますか? 質問が少し歪んでいる場合は申し訳ありません。開発をどのように行うかについてのあなたの経験は高く評価されます。ありがとう
TDD は単体テストよりもはるかに多くの機能を備えている可能性があるため、単体テストは TDD の一部にすぎないと言えます。全体としての方法論には、ソフトウェア開発のあらゆるプロセスの結果に対するテストの作成 (正しい動作の期待/要件を表す) を含めることができると思います。コードの作成、ビルド スクリプト、展開スクリプト、データベース スクリプト、データのインポート/エクスポート/変換など、何をするにしても、「これが機能したことをどのように証明できるか? テストを自動化できるか?」と自問する必要があります。 "
例として、単体テストの範囲外であるために見落とされがちですが、非常に有効なテストであり、開発プロセスで最初にロードすることが重要なものはデプロイです。
ソフトウェア開発を (ソフトウェアまたは環境アーキテクチャに) 多大な労力と変更なしに実稼働環境に簡単に展開できない場合は、本番稼働の 1 週間前ではなく、事前にこれを知っておくことが重要です。そのプロセスが完成したら、それが正しくデプロイされたことを確認するテスト方法があればいいと思いませんか?
そのプロセスを理解したら、それをスクリプト化して自動化してみませんか? 展開する必要があることが要件であることがわかっている場合は、実行する前にそのためのテストを作成してみませんか?
前にも言ったことがありますが、もう一度言います。この件に関して私が見つけた最高のリソースは、Kent Beck Signature Series の一部である、Growing Object-Oriented Software, Guided by Testsです。
TDD はテストに関するものではありません。TDDは、テストを使用してコードの設計を推進します。TDDは、最初にテストを記述してコードを設計することの嬉しい副作用としてテストを生成しますが、それはテストに関するものではありません。それはテスト方法論ではなく、目的はテストを生成することではありません。
テスト駆動開発は単体テストの一種ですか?
いいえ、それは設計方法論です。
私がTDDで理解していることから、最初にテストを作成し（失敗します）、コードを作成してから、合格するはずのテストを実行します。
あなたは非常に重要なステップを逃しています。最初にテストを書き、テストに合格するまでコードを書き、次にリファクタリングします。テストにより、安全にリファクタリングできるため、設計を調整している間も目的の動作が引き続き機能することが保証されます。テストはまた、テスト可能なコードに導き、より小さなメソッド、より短いパラメーター リスト、および他の方法論が導くよりも全体的にはるかに単純な設計を促進します。
TDD 以外に、他の種類のテストを作成しますか?
私がそうするとき、それは通常、TDD を適切に実行できなかったという兆候です (しかし、それは確かに起こります)。単体テストとユーザー受け入れテストの両方があります。どちらもコードの前に記述できますが、ユーザー受け入れテストは開発サイクルの後半に記述されることがあります。そうあるべきではありませんが、そうである場合もあります。
TDD は、元の Red-Green-Refactor ループの 5 分ほどの間の設計に関するものです。しかし、設計するものは何も残っていないため、間違いなく永遠にテストを行うことになります。TDD テストは、さらなる開発によって引き起こされるリグレッションを検出するための完璧なテスト ハーネスの一部になります。はい、そうです、テスト駆動開発は単体テストの一種であると言えるでしょう:)
しかし、最初にテストを作成するときに、必要なスタブ化についてどのように知る必要があるでしょうか?
多くの場合、TDD では、SUT が連携する全体像クラスを具体化する (迅速な) 事前モデリング セッションが必要です。
ただし、これらの共同作業者がどのように機能するかについて詳しく説明する必要はありません。モックを使用すると、基本的に、後で TDD を行ったときに実装が正しく動作するという希望的観測を適用できるため、今のところは SUT に集中できます。
以前のリリースでアプリケーションをビルドする場合、ビルドにどのような種類のテストを含めますか? ビルドは統合テストを実行しますか、それとも単体テストのみを実行しますか?
継続的インテグレーションを実践する場合、単体テストは毎回実行されることになっているため、理論的には (失敗していない) 任意のビルドを取得してリリース ビルドとして使用できます。
ただし、バージョンをリリースする前に、自動または手動の統合/受け入れテストを実行することもできます。たとえば、GUI は通常、単体テストが容易ではないため、受け入れ/統合テストは GUI のバグを追跡するための良い方法です。
ここにいくつかの質問があります。論理的な順序でそれらに対処しようとするとうまくいきません
TDD は単体テストの形式ですか?
TDDを使用する唯一の利点ではないとしても、単体テストを作成するという意味で「はい」と言います。コメンテーターによって強調されたが、あなたの質問では言及されていないトピックについて: TDD は、テスト カバレッジとドキュメント化を保証するだけではありません (優れたテストは、低レベル コード ドキュメントの最良の形式の 1 つです)。TDD を使用すると、特定の設計上の決定を行う必要があり、通常はアプリ全体の設計が改善されます。
他のテストを作成しますか?
まあ、私は他の単体テストを書いていません。TDD のポイントは、テストの開発と並行してコードを開発することです。サイクルでソフトウェアを作成する - 単一のテスト、合格するのに十分なコードのみ、コードに必要なすべての機能と動作がテストで文書化されていることを確認し、コードがテスト可能であることを確認します (作成する必要があります)。そのようにTDDを行う）。追加の単体テストは必要ないはずです
使用する必要がある他の種類のテストがあります。統合テストが最初に思い浮かびますが、他にも受け入れテストなどがあります。それらが自動化されている場合は、より簡単になります。受け入れテストを書くのはあなたではなく、あなたの顧客/利害関係者であるべきです。Fitnesse http://fitnesse.org/に興味があるかもしれません。これは、非技術者が受け入れテストを作成するのに役立つツールです。
スタブについて？
具体的な例がなければ、これを議論するのは難しいです。今言えることは、一度に 1 つのテストずつコードを書くことだけです。そうすれば、複雑なクラスがあり、その複雑な依存関係をスタブ化する方法を考えるという状況に遭遇する可能性がなくなります。
ビルドにはどのようなテストを含める必要がありますか?
私は言います-可能であれば、それらすべて！