タグ付けされた質問 「unit-testing」

Webアプリケーションを使用したユニット/統合テストについて誰かと話し合いをしましたが、1つのコアアイデアについて意見の相違があります。問題は、ユニットテストの対象となるデータベースにデータを事前に入力しておくべきだと考えている人が話していることであり、テストの実行前後に完全に空である必要があると思います。 データベースに事前入力されたデータに関する私の懸念は、データが良好な状態に維持されることを確認する方法がないことです。テスト自体はデータベース内のデータを作成、削除、変更するため、テストを開始する前にデータベースにデータを保持するのは良いことではありません。 データベースの機能をテストする最良の方法は、次のセットアップを行うことです。 テストを実際に実行する前の「セットアップ」フェーズでは、まずデータベース内のすべてのテーブルを切り捨てます 次に、実行しようとしているテストケースに必要なすべてのデータを挿入します 次に、テストケースを実行して検証します 次に、「ティアダウン」フェーズで、データベース内のすべてのテーブルを再度切り捨てます テスト対象のデータがテスト可能な優れたテストであることを保証する他の良い方法はありません。 ここに何かが足りませんか？これは、データベース関連の機能をテストする最良の方法ではありませんか？（テストを開始する前、またはテストが完了した後でも）データベースに常に存在するデータベースを事前に設定しておくと、メリットがありますか？私のプロセスを異なる方法で説明して、私のポイントをよりよく理解するためのアイデアの助けも素晴らしいでしょう（つまり、私のポイントにメリットがある場合）。

25 web-development  database  unit-testing  integration-tests 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 私はこれがあるとは思いません起動するには、繰り返しの他の質問にユニットテスト。私が助けを求めているのは、プログラマー、アナリスト、マネージャー、テスターのチームにその価値を明確にすることです。自動テストでは、ユニットテスト（JUnitなど）、BDD（JBehave、Fitness）、UI（Selenium、Watir）を区別する必要はないと思います。同意しない答えを書いてください:)） 以下は私が特定したリストです。拡張または改善に役立つ答えを探しています： 時間/コストの節約：自動化されたテストの作成は、テストケースの作成よりも時間がかかる場合があります。ただし、テストが複数回実行されることを考慮すると、自動テストを実行するためのわずかな作業（コスト/時間）が数桁少なくなります。自動テストの実行が安価であることは、時間の経過に伴うシステムの変更を促進します。 ドキュメンテーション：システムがどのように機能するかを知るためのより正確な方法は、テストよりもありません。他のドキュメントは、通常、作成された時点では古くなっていますが、テスト（少なくとも合格したもの）により、実際の動作が明らかになります。これは、エンドユーザーおよびAPIドキュメントの両方に当てはまります。 コード品質：テスト作成により、次のことが強制されます。 テストはクライアントであるため、クライアントを考慮する コードをテスト可能にすることは、多くの場合、他の大規模システムを必要としないコードを作成する方法を見つけ出すことを意味します。

25 unit-testing  selenium  tdd  bdd 

同僚は単体テストを使用することを嫌がり、代わりに簡単なテストを選択してユーザーに渡し、すべてがうまくいけばライブで公開されます。言うまでもなく、いくつかのバグは解決されます。 私はユニットテストの使用について考えるべきだと言いましたが、彼女はより多くのコードを書かなければならないことに気づいたら、それに対してすべて反対しました。これにより、特に彼女のコードがスパゲッティであり、機会があればリファクタリングしようとするので、何かを変更し、出力が同じであるかどうかを確認することができません。 それでは、私にとって最善の方法は何ですか？

25 refactoring  unit-testing 

次のようなコードの塊があります。 function bool PassesBusinessRules() { bool meetsBusinessRules = false; if (PassesBusinessRule1 && PassesBusinessRule2 && PassesBusinessRule3) { meetsBusinessRules= true; } return meetsBusinessRules; } この特定の機能には、4つのユニットテストがあるはずです。ifステートメントの各条件をテストし、falseを返すことを確認するには3つ。そして、関数がtrueを返すことを確認する別のテスト。 質問：代わりに、実際には10個の単体テストが必要ですか？考えられる各障害パスをチェックする9つ。IE： 偽偽偽 False False True False True False など、可能な組み合わせごとに。 それはやり過ぎだと思いますが、私のチームの他のメンバーの一部はそうではありません。私が見る方法は、BusinessRule1が失敗した場合、常にfalseを返す必要があり、最初にチェックされたか最後にチェックされたかは関係ありません。

25 unit-testing 

私はTDDを使って、Bit Vectorのような単純なものを開発することで、TDDを実践しようとしています。私はたまたまSwiftを使用していますが、これは言語に依存しない質問です。 My BitVectorは、struct単一のを格納し、そのUInt64上にコレクションのように扱うことができるAPIを提供します。詳細はさほど重要ではありませんが、非常に簡単です。上位57ビットはストレージビットであり、下位6ビットは「カウント」ビットであり、格納された値を実際に格納するストレージビットの数を示します。 これまでのところ、非常にシンプルな機能がいくつかあります。 空のビットベクトルを構築する初期化子 countタイプのプロパティInt isEmptyタイプのプロパティBool 等号演算子（==）。注意：これは、JavaのObject.equals()ような参照等価演算子ではなく、==Javaのような値等価演算子です。 私は周期的な依存関係の束に直面しています： イニシャライザをテストする単体テストでは、新しく構築されたを確認する必要がありBitVectorます。次の3つの方法のいずれかで実行できます。 チェック bv.count == 0 チェック bv.isEmpty == true それを確認します bv == knownEmptyBitVector 方法1は依存count、方法2は依存isEmpty（それ自体が依存しているcountため、使用する意味はありません）、方法3は依存してい==ます。いずれにしても、初期化子を単独でテストすることはできません。 のテストはcount何かを操作する必要があり、必然的に私のイニシャライザーをテストします の実装は、にisEmpty依存していますcount の実装はに==依存していcountます。 BitVector（aとしてUInt64）既存のビットパターンからを構築するプライベートAPIを導入することにより、この問題を部分的に解決することができました。これにより、他のイニシャライザーをテストせずに値を初期化できたので、「ブートストラップ」することができました。 ユニットテストが本当にユニットテストであるためには、たくさんのハックをしていることに気付きます。 この種の問題をどのように正確に回避しますか？

24 unit-testing  tdd  swift-language 

私の同僚が、私が面白いと思うアイデアを思いつきました。 TDDを行わないと想定してレビューを行う人が、コードレビュー中にテストを書くことは有益ではないでしょうか。 この質問では、これは純粋にアカデミックなプロジェクトであり、命にかかわることはないと想定しています。さらに、チームは4人です。誰もが言語を知っており、使用されるすべてのツール/ライブラリ/フレームワークに精通しており、テストを書くことができます。したがって、基本的には、上級のフルスタックではない人が忍者のエンジニアをリードしていますが、まともなコーダーです。 私が見つけた長所： レビュー中にコードのより深い理解を促し、意味のあるテストを作成します。 次に、テスト対象のコードの作成者が行ったテストのコードレビューを追加できます。 短所： コードの作成とテストの間のフィードバックループが拡大します。 編集：私はそれが「通常の」Webアプリケーションではうまく動作しないことを知っています。私が念頭に置いていたのは、細部に注意を払う必要のある複雑で科学的なアルゴリズムを実装するコーナーケースです。独自のグラフライブラリ、NLPなどの実装のようなものを想定しましょう。作成しているコードがデータベースから分離されているなど、理解するのが非常に難しいのは、ソースを理解する必要のある他の人ではありませんコードを作成し、意味のあるテストを行い、プロセス全体を、アプリケーションをクラッシュさせず、最終的に結果をゴミにするようなそれほど明白ではないバグを起こしにくくしますか？

24 programming-practices  unit-testing  testing  teamwork  workflows 

ユニットテストと統合テストの役割について、テストマネージャーと話し合いました。彼女は、開発者にユニットと統合のテスト内容とその方法を報告するように要求しました。私の考えでは、単体テストと統合テストはテストプロセスではなく開発プロセスの一部です。セマンティクスを超えて、ユニットテストと統合テストをテストレポートに含めるべきではなく、システムテスターがそれらについて心配するべきではないということです。私の推論は2つのことに基づいています。 ユニットおよび統合テストは、常にインターフェイスと契約に対して計画および実行されます。正式な契約を使用するかどうかに関係なく、メソッドが何をすべきか、つまり契約をテストします。 統合テストでは、2つの異なるモジュール間のインターフェイスをテストします。インターフェイスとコントラクトは、テストに合格するタイミングを決定します。ただし、システム全体の限られた部分を常にテストします。一方、システムのテストは、システムの仕様に照らして計画および実行されます。仕様は、テストに合格するタイミングを決定します。 ユニットテストと統合テストの幅と深さを（システム）テスターに​​伝えることには価値がありません。特定のビジネスレイヤークラスで実行される単体テストの種類を一覧表示するレポートを作成するとします。彼/彼女はそれから何を奪うことになっていますか？ それからテストすべきものとすべきでないものを判断することは、すべての単体テストと統合テストに合格してもシステムがまだ仕様どおりに機能しない可能性があるため、誤った結論です。 これは役に立たないアカデミックな議論のように思えるかもしれませんが、私と同じように厳密に正式な環境で作業している場合、私たちが物事をどのように行うかを決定する上で実際に重要です。とにかく、私は完全に間違っていますか？

24 unit-testing 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 3,000件近くのテストを作成しました。データはハードコーディングされており、コードの再利用はほとんどありません。この方法論は、私たちを尻に刺し始めました。システムが変更されると、壊れたテストの修正により多くの時間を費やすことになります。ユニット、統合、機能テストがあります。 私が探しているのは、管理しやすく保守可能なテストを書くための決定的な方法です。 フレームワーク FakeItEasy nUnit AutoFixture

24 .net  unit-testing 

私はコンサルタントであり、クライアントサイトですべての開発者に単体テストを紹介します。私の目標は、すべての新しいアプリケーションで、作成されたすべてのクラスの単体テストを確実に行うことです。 クライアントには、既存のアプリケーションのバグ修正による高いメンテナンスコストの問題があります。それらのアプリケーションの寿命は5〜15年で、新しい機能が継続的に追加されます。ユニットテストから始めることで、彼らが大いに役立つと確信しています。 開発の時間とコストに対する単体テストの効果に興味があります。 開発プロセスの一環として単体テストを書く時間はどれくらいかかりますか？ 適切な単体テストを行うことで、メンテナンスアクティビティ（テストとデバッグ）でどれくらいの時間が節約されますか？

24 unit-testing  maintenance  quality 

クラスの2つのメソッドのテストがあるとします。最初の方法では、別の層からデータを収集し、ランタイムに依存しない何らかの種類のストレージ（SQLテーブルなど）に格納するため、このテストで処理されるすべてのデータはテストにハードコーディングされます。2番目のメソッドは、最初のメソッドがデータを残した場所からデータを取得し、何らかの方法で変換（計算、特定の部分を他の場所に移動するなど）を担当します。 この2番目の方法では、最初の方法と同様に入力をハードコーディングするか、2つのテストを連続して実行し、最初のテストで実際に保存されたデータを取得して、1番目のテストが中断した場所から再開できると想定できます。 2番目のオプションを選択した場合、2つの方法がうまく機能するというのは本当に良い考えですが、1番目のテストが失敗した場合、それ以降のすべてのテストは失敗し、バグをより迅速に特定するのに役立つテストの利点がなくなります。 最初のオプションを選択した場合、各メソッドは独立して分離され、テストされますが、それらが実際に適切に連携できることを本当に知ることはありません。 ここでより良いオプションはどれですか？ハードコーディングを使用して分離されたメソッドごとに単一のテストを実行し、次に両方のメソッドを1つに含むより大きなテストを実行するなど、何らかの方法がありますか？

24 testing  unit-testing  tdd 

私は現在、学期プロジェクトのために、単体テストや統合テストなど、複数のタイプのテストを実行する必要があるソフトウェアテストのクラスにいます。統合テストの場合、教授は統合テストにモックとモック作成ライブラリ（EasyMockやMockitoなど）を使用すると言いました。私はかなり混乱しています。統合テストとは、クラス、モジュール、サービスなどの外部をテストすることです。複数のクラスとサービスをテストする場合、統合テストでモックとスタブを使用するのが適切なのはなぜですか？

24 unit-testing  testing  integration-tests  mocking 

これまでに継続的インテグレーションシステム（CI）を使用したことがありません。私は主にMATLAB、PythonまたはPHPでコーディングします。これらのどちらにもビルドステップがなく、CIがどのように作業に使用できるかわかりません。大企業の大規模プロジェクトの友人から、言葉は関係ないと言われました。 ビルドステップがない場合、CIがどのように役立つかわかりません。CIは、単体テストを実行するテスト環境と考えることができます。何か不足していますか？

23 unit-testing  continuous-integration  integration-tests  build-system 

私はテストが開発を促進する必要があることを知っている限り、c＃を使用してTDDを学んでいます。つまり、最初にテストに合格するために最低限のコードを書いてからリファクタリングを行ってから失敗するテストを書きます。 しかし、「実装ではなく、インターフェイスするプログラム」とも言われているため、最初にインターフェイスを記述します。ここから混乱が始まります。最初にInterfaceを書いている場合、2つのことに違反しています。 インターフェイス用に記述されたコードはtestによって駆動されません。 単純なクラスでそれを書くことができるのは、明らかに最低限のものではありません。 インターフェースのテストを書くことから始めなければなりませんか？実装なしで何をテストするのですか？ この質問がそれについて愚かに残念に思えるが、私は全く混乱しています。文字通りに物事を取っているかもしれません。

23 c#  unit-testing  tdd 

オンライン機能を必要とするプライベート機能を持つクラスの機能を単体テストするとき。それをどのようにテストしますか？ 例えば： public class Foo { public int methodA() { int val = goOnlineToGetVal(); return val; } private int goOnlineToGetVal() { CloudService c = new CloudService(); int oval = c.getValueFromService(); return oval; } } 機能をテストする場合、「methodA（）」は「goOnlineToGetVal（）」を使用しようとしますが、このテストが機能なしで実行された場合、オンラインに移行しようとします。オンラインに接続せずに、どのように100％のクラスをカバーしますか

23 unit-testing  junit 

私たちの会社では通常、Webサイト/ Webアプリのエンドツーエンドのテストを必ず作成します。つまり、URLにアクセスし、フォームに入力し、フォームを別のURLに送信して、ページの結果を確認します。これは、フォームの検証、HTMLテンプレートに正しいコンテキスト変数があることなどをテストするために行います。 また、基になるロジックを間接的にテストするためにも使用します。 同僚から、この理由は、エンドツーエンドのテストに合格する限り、任意の時点で基になる実装をリッピングおよび変更できるためだと言われました。 この種のデカップリングが理にかなっているのか、それとも小さなコード単位のテストを書くのを避けるための方法なのだろうか？

23 unit-testing  tdd  acceptance-testing