チェックイン前に開発者が実行するテストスイートを何と呼びますか?[閉まっている]


8

私は、既存のプロジェクトに自動テストを追加するプロジェクトに取り組んでいます。中央コンポーネントから始めて、開発者環境ではありますが、コードモジュールレベルでの単体テストと、コンポーネント全体で実行されるテストの両方をセットアップします。このテストスイートは、コードチェックインの前に合格する必要があり、各開発ブランチの継続的インテグレーションシステムによって実行されることを意図しています。

これは何と呼ぶべきでしょうか?現在、これを「開発ユニットテスト」と呼んでいますが、ユニットテスト以上のものが含まれているため、私の知識の面では、それは完全に適切ではないと述べています。そして、私たちのビジョンは、このスイートが時間とともに成長し、完全な製品受け入れテストを含めることです。

ここに何か入力はありますか?それとも、名前についての議論をやめて、テストを書くべきでしょうか?

更新

みなさん、良い議論をありがとう!私が結論を下しているのは、実際には「共通の」定義は存在しないということだと思います。各プロジェクト/チームには、テクノロジー(Java、C#、Rubyなど)に応じて、そのプロジェクトに最も意味のある名前が付けられますおよび使用中の方法論(古い学校の滝、スクラム、XPなど)。


+1パターンは概念の一般的な表現を定義するのに価値があったので、XxxxxCeckinsのよい表現は良いアイデアです。新しいリリース候補を作成したい場合に実行する必要があるリリース候補チェックインの適切な表現について、コミュニティが考えている場合もあります。これらのテストには、通常の各開発者Xxxxcheckinでは実行できない長期実行テストも含まれています
k3b

回答:


10

これらは、MSFT TFS では「ゲートチェックイン」として知られていますhttp://blogs.msdn.com/b/patcarna/archive/2009/06/29/an-introduction-to-gated-check-in.aspx


1
TFSを使用していない場合でも、「ゲートテスト」と呼ぶのは良い考えだと思います。それらは、ある状態から別の状態への進行を管理します。これは、新しいコードが機能するかどうかを確認するだけとは異なります。
ケイトグレゴリー

1
または、Subversionを使用する場合は、プリコミットテスト。
rwong

1
@rwong、これは答えになることがあります。
仕事

2

好きなように呼んでください、それは問題ではありません。重要なのは、テストの品質とテストの実行です。

私たちのテストは自動受け入れテストですが、ここでは単に「テスト」と呼んでいます。のように:

  • 「テスト」を修正する
  • あなたは「テスト」を破った
  • 「テスト」を書きましたか
  • この「テスト」はひどいので、書き直しました

0

私はそれらを「テスト」と呼んでいます。これは、「自動化された単体テスト」について話していることを意味し、これらが高速であることを必然的に意味しています(数秒から数分は、より頻繁に経験したものです)。

たとえば、チェックイン時に自動的に、または夜間に1回実行される他のテストがある場合があります。これらは時間がかかる傾向があります。30分から数時間の間の何か。通常、これらを「機能テスト」、「回帰テスト」、または「低速テスト」と呼びます。


0

私の経験から:

単体テストは、特定のモジュールをカバーするテストまたはテストのセットです。オブジェクト指向プログラミングでは、モジュールは通常、関数またはクラスです。単体テストはテストスイートにグループ化されます。単体テストは、回帰テストとスモークテストの構成要素であり、システムまたはシステムの一部の意図された動作のドキュメントとして役立つ場合があります。

回帰テストは、変更されたモジュールでユニットテストのほとんどまたはすべてを実行する行為です。これにより、変更後のモジュールは、変更後も期待どおりに機能し続けます。

煙のテストは、変更されていないモジュールに対して(小規模-煙のテストをかなり速くしたい)多数の単体テストを実行して、モジュールの変更によって他のモジュールに意図しない副作用が発生しないことを確認する行為です。焦点は通常、変更されたクラスとの関連付けを持つクラスと、アプリケーションに主要な機能を提供するモジュールです。

ビルド環境によっては、これらのいずれかが開発者によって自動化または実行される場合があります。コミットされた変更セットは、回帰テストに許容できないほど長い時間がかからないように十分に小さくする必要があり、煙のテストはかなり高速になるように設計されています。通常、コードをチェックインする前に、少なくとも回帰テストとスモークテストを実行して、ビルドを壊さないようにします。私は通常、ビルドシステムがすべてのテストケースのステータスを定期的に実行および報告するように設計されているのを見てきました。


0

チェックインする前にコードベース全体で実行すると、回帰テストになります。

変更したビットをテストするだけであれば、単体テストです。

システムレベルのバグのテストを追加して修正すると、それは回帰テストになります。

あなたが後退している場合のテスト:逆方向に。

バグは特定の場所に集まる傾向があり、一部のバグは再発するため、回帰テストを行う価値があります。

システムレベルのテストを行うという規律に耐えられる場合は、そこに回帰テストを追加すると効果があります。壊れやすいサブシステムはすべて、回帰テストに組み込まれます。

実話。


-1

自動化された単体テストは、私がいつもそれらを呼んできたものです。


ここでの問題の一部は、この組織が多くのことを「単体テスト」と呼んでいることです。私は彼らにもっと業界標準の定義を使わせようとしている。したがって、これらの自動化された高レベルのテストを指すために「単体テスト」という用語を使用することは本当に避けたいと思います。
dpassage

-1

正式な用語があるかどうかはわかりませんが、自動テストと呼んでいます。そこにある単位という言葉は正確ではないことに同意します。



-1

私たちは通常、それらを煙テスト、健全性テスト、または優先度1のテストと呼びます。優先度2のテストはチェックイン後に行わ、次に優先度3のテストがスケジュールされたビルドで実行されます。テストの最後のセットである優先度4のテストは、週末に実行される特別なビルドがある場合に実行されます-実行に長い時間がかかるためです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.