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

私がこのようなユニットテストを持っているとしましょう： let myApi = new Api(); describe('api', () => { describe('set()', () => { it('should return true when setting a value', () => { assert.equal(myApi.set('foo', 'bar'), true); }); }); describe('get()', () => { it('should return the value when getting the value', () => { assert.equal(myApi.get('foo'), 'bar'); }); }); }); だから今私は2つの単体テストを持っています。APIで値を設定します。もう1つのテストでは、適切な値が返されることを確認します。ただし、2番目のテストは最初のテストに依存しています。2番目のテストが他に依存していないことを確認するという唯一の目的.set()で、2番目のテストの前にメソッドを追加する必要get()がありますか？ …

9 unit-testing 

バックグラウンド C＃.NETでプロジェクトに取り組んでいますが、Visual Studioのソリューションに新しい単体テストプロジェクトを追加しました。私がこれをいつもやっている方法は： 新しい単体テストプロジェクトを作成します。 そのプロジェクトに、テスト中のプロジェクトへの参照を含めます。 プロジェクトを含める（using）だけです。 あなたができる他の方法は... 新しい単体テストプロジェクトを作成します。 そのプロジェクトに、テスト中のプロジェクトへの参照を含めます。 作るユニットテストプロジェクトが持つ名前空間を共有テスト中のプロジェクトを。 質問 .NETの世界のプロジェクトでこれを行うための受け入れられた方法はありますか、またはこれは単なる意見であり、それ以上のものはありませんか？

9 c#  unit-testing  tdd  visual-studio  project-structure 

私は依存性注入について学んでいます。関数型ライブラリを作成するときにその魅力を見ることができますが、ライブラリを使用する人にもなると、それがどのように解決するのかわかりません。 テストするものがあまりないので、ライブラリのテストがはるかに簡単になります。 しかし、最終的には、ライブラリを使用するときに注入された関数をテストし、標準ライブラリの関数のモックとスタブを処理する必要があります。 これは、Node.jsで扱っている具体的なケースです。 function compile(options) { var files = options.files; var texCompiler = options.texCompiler; var pdfMerger = options.pdfMerger; return Promise.all(files.map(texCompiler(files))) .then(pdfMerger); } 注入：それはテストに簡単ですモックオブジェクトとして、あるいはスパイをtexCompilerし、pdfMerger機能が本当にすべてではあまり行っていないので、ケーキの一部です。私がテストできるのは、両方の関数が正しい順序で呼び出されることだけです。 とはいえ、最終的には私の関数texCompilerやpdfMerger関数をテストする必要はありません。彼らはそのようなものに見えます： var tex2Pdf = Promise.method(function tex2Pdf(tex_doc) { var latex_command = 'pdflatex'; var pdf_output_filename = path.parse(tex_doc).name + '.pdf'; var cmd = latex_command + ' ' + tex_doc; …

9 design-patterns  javascript  unit-testing  dependency-injection 

作業中の新しいコードの単体テストをいくつか作成し、コードレビューのために送りました。私の同僚の1人が、多くのテストで使用される変数をテストのスコープ外に配置した理由についてコメントしました。 私が投稿したコードは本質的に import org.junit.Test; public class FooUnitTests { @Test public void testConstructorWithValidName() { new Foo(VALID_NAME); } @Test(expected = IllegalArgumentException.class) public void testConstructorWithNullName() { new Foo(null); } @Test(expected = IllegalArgumentException.class) public void testConstructorWithZeroLengthName() { new Foo(""); } @Test(expected = IllegalArgumentException.class) public void testConstructorWithLeadingAndTrailingWhitespaceInName() { final String name = " " + …

9 java  unit-testing  tdd 

CI / CDワークフローでTDDにプッシュするために、いくつかの新しいプロジェクト用にBambooサーバーをセットアップしているところです。確かに、単体テストは素晴らしいですが、そこにあるのと同じくらいログだけです。 これは、特定のブランチ（つまり、開発ブランチとメインリリースブランチ）のGIT事前受信フックでより良いかもしれませんが、コードカバレッジを実施する場合は、どのように実施する必要がありますか。私はコミッターを信頼してコードがカバーされていることを確認できて嬉しいですが、勤勉さと一貫性を除いて、これらの事柄をどのように維持するのでしょうか？ 要するに、コミット段階またはビルド段階のいずれかで、他の人がどのようにテストカバレッジを自動プロセスとして実施するかを確認したいと思います。

9 unit-testing  test-coverage 

時間に依存する機能に取り組んでいるとき...単体テストはどのように整理しますか？単体テストのシナリオがプログラムの「今」を解釈する方法に依存する場合、どのように設定しますか？ 2番目の編集：数日後にあなたの経験を読んでください この状況に対処するための手法は、通常、次の3つの原則の1つを中心に展開することがわかります。 依存関係を追加（ハードコード）する：時間関数/オブジェクトの上に小さなレイヤーを追加し、常にこのレイヤーを通じてdatetime関数を呼び出します。このようにして、テストケース中に時間を制御できます。 モックを使用する：コードはまったく同じままです。テストでは、時間オブジェクトを偽の時間オブジェクトに置き換えます。ソリューションには、プログラミング言語によって提供される本物の時刻オブジェクトを変更することが含まれる場合があります。 依存性注入を使用する：時間参照がパラメーターとして渡されるようにコードをビルドします。次に、テスト中にパラメーターを制御します。 言語に固有の手法（またはライブラリ）は大歓迎であり、例示的なコードが追加されれば強化されます。次に、どのプラットフォームに同様の原則を適用できるかが最も興味深い。そしてはい... PHPですぐにそれを適用できる場合は、より良いよりも優れています;） 簡単な例から始めましょう：基本的な予約アプリケーションです。 JSON APIと、リクエストメッセージと確認メッセージの2つのメッセージがあるとします。標準的なシナリオは次のようになります。 あなたはリクエストをします。トークンを使用して応答を取得します。その要求を満たすために必要なリソースは、システムによって5分間ブロックされます。 トークンで識別されるリクエストを確認します。トークンが5分以内に発行された場合、トークンは受け入れられます（リソースは引き続き使用可能です）。5分以上経過した場合は、新しいリクエストを作成する必要があります（リソースは解放されています。リソースの可用性をもう一度確認する必要があります）。 ここに対応するテストシナリオがあります： お願いします。受け取ったトークンで（すぐに）確認します。私の確認は受け入れられました。 お願いします。3分待ちます。受け取ったトークンで確認します。私の確認は受け入れられました。 お願いします。6分待ちます。受け取ったトークンで確認します。確認が拒否されました。 これらの単体テストをプログラムするにはどうすればよいですか？これらの機能をテストできるようにするには、どのアーキテクチャを使用する必要がありますか？ 編集注：リクエストを送信すると、時間はミリ秒に関する情報を失う形式でデータベースに保存されます。 余計ですが、少し冗長かもしれません。ここで、「宿題」をやっていることがわかった詳細について説明します。 私は自分の時間関数に依存して機能を構築しました。私の関数VirtualDateTimeには、新しいDateTime（）を呼び出すために使用した静的メソッドget_time（）があります。この時間機能を使用すると、「今」の時間をシミュレートおよび制御できるため、「今すぐ21st jan 2014 16h15に設定します。リクエストを送信します。3分先に進みます。確認を行います」のようなテストを作成できます。これは、依存関係を犠牲にしてうまく機能し、「それほどきれいではないコード」です。 もう少し統合されたソリューションは、追加の「仮想時間」機能を備えたDateTimeを拡張する独自のmyDateTime関数を構築することです（最も重要なことは、今、私が望むものに設定することです）。これにより、最初のソリューションのコードは少しエレガントになりますが（新しいDateTimeではなく新しいmyDateTimeを使用）、非常によく似たものになります。独自のクラスを使用して機能を構築する必要があるため、依存関係が作成されます。 でも、DateTime関数をハッキングして、必要なときに依存関係で機能させるようにしています。ただし、クラスを別のクラスで置き換える簡単で便利な方法はありますか？（私はそれに対する答えを得たと思います：下記の名前空間を参照してください）。 PHP環境では、「Runkit」を読んで、これを動的に行うことができます（DateTime関数をハックする）。DateTimeに関する変更を行う前に、テスト環境で実行していることを確認し、運用環境でそのままにしておくことができるのはすばらしいことです[1]。これは、手動のDateTimeハックよりはるかに安全でクリーンに聞こえます。 時間を使用する各クラスの時計関数の依存性注入[2]。これはやりすぎではありませんか？一部の環境では非常に役立つことがわかります[5]。この場合、私はあまり好きではありませんが。 すべての関数の時間の依存関係を削除します[2]。これは常に実現可能ですか？（以下のその他の例を参照） 名前空間の使用[2] [3]？これはかなりよさそうだ。\ DateTimeを拡張する独自のDateTime関数でDateTimeをモックすることができます... DateTime :: setNow（ "2014-01-21 16:15:00"）とDateTime :: wait（ "+ 3 minutes"）を使用します。これは私が必要とするもののほとんどをカバーしています。しかし、time（）関数を使用するとどうなりますか？または他の時間関数？私はまだ元のコードでの使用を避けなければなりません。または、コードで使用しているPHP時間関数がテストでオーバーライドされていることを確認する必要があります...これだけを実行できるライブラリはありますか？ スレッドのためだけにシステム時間を変更する方法を探していました。何もないようです [4]。これは残念です。「このスレッドの2014年1月21日16h15に時間を設定する」ための「単純な」PHP関数は、この種のテストに最適な機能です。 exec（）を使用して、テストのシステム日時を変更します。これは、サーバー上の他のものを台無しにすることを恐れていない場合に機能します。また、テストを実行した後、システム時間を戻す必要があります。それはいくつかの状況でトリックを行うことができますが、かなり「ハッキー」に感じます。 これは私にとって非常に標準的な問題のように見えます。しかし、それを処理するための単純で一般的な方法がまだありません。多分私は何かを逃した？あなたの経験を共有してください！ 注：同様のテストが必要になる可能性がある他の状況をいくつか示します。 なんらかのタイムアウトで機能する機能（チェスゲームなど） 特定の時間にイベントをトリガーするキューを処理します（上記のシナリオでは、次のように続けることができます。予約が始まる1日前に、すべての詳細をメールでユーザーに送信します。テストシナリオ...） 過去に収集されたデータを使用してテスト環境をセットアップしたい-今のように表示したい。[1] …

9 unit-testing  real-time 

HSQLDBは素晴らしいです。また、組み込みモード（専用サーバーは不要）を備えているため、Proof of Conceptsなどの迅速なプロトタイピングが可能になり、さまざまなデータをすばやく簡単に保存できるため、本番環境ですぐに使用できるアプリケーションにも最適です。 ただし、私が過去数年取り組んできたプロジェクトの少なくとも90％は、SQLデータベースを何らかの方法で処理する場合、組み込みHSQLDBを使用するユニットテストを避けられません。 確かに、これらのプロジェクト（ほとんどの場合、標準のMaven構造を使用します）には、大量の「単体テスト」（または少なくとも、ある種のテストがありますが、「単体テスト」領域にあります）があります。いくつかのCRUD操作を実行して結果を確認するために、HSQLDBの1つ以上の埋め込みインスタンスを使用するプロジェクト（「src / test / java」など）の）。 私の質問は、これはアンチパターンですか？HSQLDBは​​簡単に統合でき、組み込みサーバーは非常に軽量であるため、実際のデータベースの「モックアップ」として見過ごされがちですが、そうでない場合はどうでしょうか。（それらのそれぞれは、「何か」で構成されているので、このようなテストは、より統合テストのように扱われるべきではないと、データベース・サーバーとの「何か」の統合という）？または、「単体テスト」定義に何か欠けているのでしょうか。このようにHSQLDBを使用すると、「単体テスト」定義の「依存関係を模擬し、単体のみをテストする」部分に固執すると言えます。

9 database  unit-testing  mocking  integration-testing 

次のように、配列用の拡張メソッドをC＃でbyte16進文字列にエンコードする拡張メソッドを記述したとします。 public static class Extensions { public static string ToHex(this byte[] binary) { const string chars = "0123456789abcdef"; var resultBuilder = new StringBuilder(); foreach(var b in binary) { resultBuilder.Append(chars[(b >> 4) & 0xf]).Append(chars[b & 0xf]); } return resultBuilder.ToString(); } } 次のように、NUnitを使用して上記のメソッドをテストできます。 [Test] public void TestToHex_Works() { var bytes = new …

8 unit-testing  static-methods 

進む この質問をする前に、SEに関する多くの関連する質問を含め、多くのことを読みました。 （ソフトウェアエンジニアリングSE）目的がわからないコードのテストを書く （ソフトウェアエンジニアリングSE）ユニットテスト初心者チームはユニットテストが必要 （ソフトウェアエンジニアリングSE）レガシーコードを自動テストで改造するためのベストプラクティス （ソフトウェアエンジニアリングSE）大規模なレガシーシステムを単体テストする方法 （ブログ投稿）単体テスト環境をモックアップする方法 しかし、助けを求めて読んだ後、かゆみはまだ引っかかれていないと感じざるを得ません。 TL; DR 実行、シミュレーション、読み取り、または簡単に理解できないレガシーコードの単体テストを作成するにはどうすればよいですか？おそらく意図したとおりに機能するコンポーネントに役立つ回帰テストは何ですか？ 全体像 私は大学院に移行しているので、再び夏の帰国研修生です。私の仕事には次の要件が含まれます。 特定の製品について、ソフトウェアチームが既存のプロジェクトとの互換性を失うことなくIDEおよびJUnitバージョンをアップグレードできるかどうかを評価します。 既存のJavaコード（主にJavaではない）の一部のコンポーネントの単体テストを開発します。ユニットテストとTDDは、使用する必要がある非常に貴重なツールであることをソフトウェアチームに納得させたいと思います。（現在、0％のコードカバレッジがあります。） どういうわけか、重要なシステムのカウボーイコーディングの時代を終わらせてください。 ソースコードのコピーを入手した後、この製品の機能と動作を理解できるように、ビルドして実行しようとしました。できませんでした。私は上司に自分のやり方を尋ね、実際に機能するビルドスクリプトを含む、それをビルドできる新しいスタンドアロンマシンを発行されました。彼らの予想通り、製品コードは設計された組み込みシステムでのみ実行されるため、それも機能しませんでした。しかし、彼らはこの目的のためにシミュレーターを持っているので、彼らはシミュレーターを手に入れ、このマシンにそれを置いてくれました。シミュレータも機能しませんでした。代わりに、私は最終的に特定の画面のGUIのプリントアウトを受け取りました。また、700,000以上のJava LOC内のどこにもコードコメントがないため、把握がさらに困難になります。さらに、彼らのプロジェクトが新しいIDEと互換性があるかどうかを評価する問題がありました。特に、彼らのコードは、彼らが使用しているまさにそのIDEバージョンに適切にロードされませんでした。 私の在庫は次のようになっています： NetBeans 8、9、10、11 JUnit 4、5 特定の製品のソースコード（700,000以上のJava LOCを含む） 実質的にコードコメントはありません（場合によっては署名） 既存のテストはありません GUIウィンドウの物理的な写真 画像内のコンポーネントについて説明していないソフトウェア設計ドキュメント（109ページ） 少なくとも理論的には実行可能なテストを書くのに十分です。そこで、このコンポーネントについて基本的な単体テストを試しました。しかし、モデル、マネージャー、DB接続など、依存関係として持つオブジェクトを初期化できませんでした。基本的な単体テスト以外にJUnitの経験はあまりないので、次のセクションに進んでください。 私の読書から学んだこと モッキング：単体テストを作成する場合、本番環境での依存関係のために、モック変数を用意する必要がありますsetUp。 ここの誰もがマイケルフェザーズの著書「レガシーコードを効果的に使用する」を寛大に提案しています。 回帰テストは、おそらく開始するのに適しています。統合テストを試すのに十分な兵器がないと思います。回帰テストは、ソフトウェアチームにすぐに満足感を与えるでしょう。ただし、私は彼らの既知のバグにアクセスできません。しかし、私はたぶん尋ねることができました。 そして今、私がまだ疑問として持っている不確実性を明確にする試み。基本的に、私はこれらのテストを作成する方法の一部を理解していません。（おそらく）上司からこれ以上のガイダンスを受け取らないと想定すると、このコンポーネントの機能を理解するだけでなく、どのテストが回帰テストとして実際に役立つかを判断するのは私の球場です。 このようなプロジェクトに携わってきた専門家として、このような状況で単体テストを作成する方法について何かアドバイスはありますか？

8 unit-testing  testing  mocking  legacy  legacy-code 

問題は、現在のスレッドがメインスレッドであることを表明する単体テストを記述することには意味があるのでしょうか。長所短所？ 最近、サービスのコールバックのために現在のスレッドをアサートする単体テストを見ました。いいアイデアだとは思いませんが、もっと統合テストだと思います。私の意見では、単体テストはメソッドを個別にアサートする必要があり、サービスの利用者の性質については知らないはずです。 たとえば、iOSでは、このサービスのコンシューマーは、デフォルトでメインスレッドでコードを実行するための制約を持つUIであることが意図されています。

8 architecture  unit-testing  object-oriented-design  multithreading  ios 

私が以下の（過度に単純化された）クラス構造を持っていると仮定します： class Base { public: Base(int valueForFoo) : foo(valueForFoo) { }; virtual ~Base() = 0; int doThings() { return foo; }; int doOtherThings() { return 42; }; protected: int foo; } class BarDerived : public Base { public: BarDerived() : Base(12) { }; ~BarDerived() { }; int doBarThings() { return …

8 c++  unit-testing  testing 

複雑な単体テスト機能がある場合： def do_everything(): # turn twizzles # push buttons # move mountain そして、それをいくつかの小さな単位にリファクタリングします： def do_everything(): turn_twizzles() push_buttons() move_mountain() def turn_twizzles(): # turn twizzles def push_buttons(): # push buttons def move_mountain(): # move mountain これらの小さなユニット用の追加の単体テストを書くのに時間を無駄にしていますか？

8 unit-testing  refactoring 

タイトルを少し拡張するために、他の関数またはクラスが依存する純粋な関数を明示的に宣言する（つまり注入する）必要があるかどうかについて、結論を出そうとしています。 それらが要求せずに純粋な関数を使用する場合、テスト可能性が低く、設計が悪い特定のコードはありますか？私は単純なものから純粋な機能の任意の種類のために、問題の結論に取得したいと思い、ネイティブ関数（例えばmax()、min()-言語に関係なく）今度は他の純粋な機能に暗黙的に依存してもよいことを習慣に、より複雑なもの。 通常の懸念は、一部のコードが依存関係を直接使用するだけの場合、それを単独でテストすることができない、つまり、あなたが黙って持ってきたものすべてを同時にテストすることです。しかし、これは、小さな関数ごとに実行する必要がある場合、かなりのボイラープレートを追加するので、これがまだ純粋な関数に当てはまるかどうか、なぜか、またはなぜそうでないのかと思います。

8 unit-testing  dependency-injection  pure-function 

私の個人的なプロジェクトでTDDを実践しようとしています。新しいテストを追加した後、既存の実装に基づいて最初から合格する場合の状況にどのように対処するのでしょうか。 一方では、新しいテストは、設計の追加のドキュメントと、想定外の偶発的な違反からの保護を提供します。 一方、コードを変更せずにテストに合格した場合は、実際に何をテストするかが「疑わしい」ものです。 基本的に、すでに実装された動作を主張するテストの正確さを確認するために何ができるでしょうか？

8 unit-testing  tdd 

私のチーム内での最近の議論は私を不思議に思いました。基本的なトピックは、機能/統合テストでいくら、何をカバーするかということです（確かに、それらは同じではありませんが、例は重要ではないのでダミーです）。 次のような「コントローラ」クラスがあるとします。 public class SomeController { @Autowired Validator val; @Autowired DataAccess da; @Autowired SomeTransformer tr; @Autowired Calculator calc; public boolean doCheck(Input input) { if (val.validate(input)) { return false; } List<Stuff> stuffs = da.loadStuffs(input); if (stuffs.isEmpty()) { return false; } BusinessStuff businessStuff = tr.transform(stuffs); if (null == businessStuff) { return false; …

8 java  unit-testing  testing  test-automation  integration-testing