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

ユニットテストは、ソースコードの個々のユニットをテストして、それらが使用に適しているかどうかを判断する方法です。

2
「アサーションフレームワーク」とは何ですか?
js-test-driverユニットテストフレームワークについて読んでいたとき、フレームワークの背後にいる連中がアサーションフレームワークと統合することを意図していることがわかりました。アサーションフレームワークとは何ですか?一種の単体テストフレームワークですか?もしそうなら、そのようなフレームワークに固有のものは何ですか?

2
アプリケーションとUIコードを単体テストするにはどうすればよいですか?
私は単体テストを書くのが大好きで、コードをテストしたり、リグレッションを防止したりするのに優れた方法であることに同意します。しかし、私が日々取り組んでいるコードの大部分はアプリケーションであるため、自分で書くことができないことに気づきましたユーザーにUIを表示するコード。アプリケーションコードを単体テストする良い方法はありますか?ここでのベストプラクティスは何ですか? 私はフレームワークなどの特定の答えを探していません。しかし、一般的に、この問題にどのように取り組みますか?

3
低レベルのコンポーネントでTDDを実行することは良い考えですか?
低レベルのドライバーまたはOSコンポーネント/カーネルの作成を検討しています。 osdev.orgの人々は、重要なビットが有意義にこの方法をテスト可能されていないことを考えているようだが、私は人々が異なったと思ったいくつかの議論を読んだことがあります。私は見回しましたが、低レベルコンポーネントのTDDの実際の例を見つけることができませんでした。 これは実際に人々が行うことですか、それとも実際にはそれを行う良い方法がないために理論的に人々が話していることですか?

3
単体テスト、フレームワークの前または後に記述しますか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 これが私の最初の質問なので、簡潔にまとめておきます。 単体テストを作成するときは、それらの基礎となるフレームワークを作成する前または作成した後でテストする必要がありますか?これは私のCEOと社長の間の議論で出てきました、そして私はこれについてあなたの意見を望みました。 個人的に、私は常に最初にコードを記述し、次にユニットテストを記述しましたが、あなたはどうですか?

1
1行の関数で構成されたデータ変更パイプラインの単体テスト
メアリーローズクックの「関数型プログラミング入門」を読んで、アンチパターンの例として def format_bands(bands): for band in bands: band['country'] = 'Canada' band['name'] = band['name'].replace('.', '') band['name'] = band['name'].title() 以来 関数は複数のことを行います 名前は説明的ではありません 副作用があります 提案された解決策として、匿名関数のパイプライン化を提案します pipeline_each(bands, [call(lambda x: 'Canada', 'country'), call(lambda x: x.replace('.', ''), 'name'), call(str.title, 'name')]) ただし、これにはテストしにくいという欠点があります。少なくともformat_bandsには、意図したとおりに機能するかどうかを確認する単体テストがありますが、パイプラインをテストする方法はありますか?あるいは、匿名関数は説明不要なので、テストする必要がないという考えですか? このための実際のアプリケーションは、pandasコードをより機能的にすることです。「変更」機能の中にある種のパイプラインがあることがよくあります def munge_data(df) df['name'] = df['name'].str.lower() df = df.drop_duplicates() return df または、パイプラインスタイルで書き換えます。 def munge_data(df) munged …

2
ヒューリスティックアルゴリズムを単体テストするにはどうすればよいですか?
ルート検索アルゴリズムがあるとします。 def myHeuristicTSP(graph): /*implementation*/ return route これをユニットテストしたいと思います: class TestMyHeuristicTSP: def testNullGraphRaiseValueError(self): self.assertRaises(ValueError, myHueristicTSP(None)) def testSimpleTwoNodeGraphReturnsRoute: self.assertEquals(expectedResult, myHeuristicTSP(input)) 問題は、非ヒューリスティックTSPアルゴリズムの場合、さまざまなグラフを提供し、常に絶対最短ルートを返すことを確認できることです。 しかし、ヒューリスティックアルゴリズムはまだ確定的ではありますが、予測可能性が低いため、アルゴリズムがどのように機能するかを理解し、それらのエッジケースを見つけることを単に目的としていますか?

6
RESTサーバーに対するRESTクライアントのテスト。フィクスチャーを行うには?
単体テストを作成するときは、フィクスチャを使用するのが一般的です。テスト可能なデータが少ないため、次のように言えます。1.すべてのクライアントにWilly Wonkaを含めます。2.クライアント3を削除し、クライアントにWilly Wonkaが含まれないようにします。 単体テストではそれで問題ありません。セットアップ/ティアダウンを使用して、フィクスチャを再ロードするか、トランザクションをロールバックします。したがって、テストの作成、更新、削除はトランザクション内で行われます。新しい一時データは、そのテストの間だけ保持され、その後リセットされます。 しかし、RESTサーバーをRESTクライアントから分離した場合はどうでしょうか。 RESTクライアントが正しく読み取っているだけでなく、正しく作成、更新、削除されていることを確認します。 リモートテストRESTサーバーに対してこれを行う方法の例や提案を見つけることができませんでした。 フィクスチャのみを提供するテストRESTサーバーがあるとします。HTTPの完全なステートレスの性質は、「BEGIN TRANSACTION」と「ROLLBACK TRANSACTION」または「RELOAD FIXTURES」タイプのメッセージを送信するのが難しいことを意味しますよね? 私はこれを最初にしたくないので、これについて別の考え方が必要だと感じています。 助言がありますか?
10 unit-testing  api  rest 

5
この場合、テストごとに1つのアサートに固執していますか?
テストしているクラスがあります。クラスには関数があります:apply(List<IRule> rules, List<ITarget> targets); 1つのテストで、各ターゲットが1つのルールaに渡されていることを確認します。 rule1.AssertWasCalled(fnord => fnord.Test(target1)); rule1.AssertWasCalled(fnord => fnord.Test(target2)); rule1.AssertWasCalled(fnord => fnord.Test(target3)); 自分を単一の表明文に限定することはかなりホブゴブリンだと私には思えます。この仮定は正しいですか、それとも各ターゲットが実際にテストされたと断言できる他の方法がありますか?

9
オブジェクトをコンストラクターに渡すか、クラスでインスタンス化する必要がありますか?
次の2つの例を検討してください。 オブジェクトをコンストラクターに渡す class ExampleA { private $config; public function __construct($config) { $this->config = $config; } } $config = new Config; $exampleA = new ExampleA($config); クラスのインスタンス化 class ExampleB { private $config; public function __construct() { $this->config = new Config; } } $exampleA = new ExampleA(); プロパティとしてのオブジェクトの追加を処理する正しい方法はどれですか?いつどちらを使用すればよいですか?単体テストは私が使用するべきものに影響しますか?

2
単体テストユーティリティクラス
私たち全員が、さまざまなソースからの使用のために、静的メソッドのみを含むいくつかのユーティリティクラスを持っています。ここで、このコードのテストに向けて実行できる2つの方法があります。 アプローチ1: ユーティリティクラス用に個別の単体テストを用意します。それらが呼び出されているところはどこでも、PowerMockなどのプロビジョニングが用意されているテストフレームワークを使用して相互作用を模擬します。これは基本的に、ユーティリティクラスをシステムの個別のコンポーネントとして扱い、個別にテストして保守する必要があります。 アプローチ2: ユーティリティクラスの単体テストを記述しないでください。ただし、このユーティリティクラスと対話する他のコアクラス用に記述されたテストでは、その相互作用が発生します。これにより、このユーティリティクラスで記述されたコードがさまざまなユースケースに対して適切にテストされることが本質的に保証されます。何かが壊れた場合、他のコンポーネントのテストはそれをキャッチできるはずです。 どちらのアプローチが望ましいか、または他の方法でこれに取り組む方法があるかどうかについて、あなたの考えを共有してください。

4
リファクタリング-すべてのテストに合格する限り、単純にコードを書き直すことは適切ですか?
最近、RailsConf 2014の「All the Little Things」を視聴しました。この講演中に、Sandi Metzは、ネストされた大きなifステートメントを含む関数をリファクタリングします。 def tick if @name != 'Aged Brie' && @name != 'Backstage passes to a TAFKAL80ETC concert' if @quality > 0 if @name != 'Sulfuras, Hand of Ragnaros' @quality -= 1 end end else ... end ... end 最初のステップは、関数をいくつかの小さなものに分割することです: def tick case name when 'Aged …

3
ユニットテストを手作業で書くのは例による証明ですか?
JUnitテストの記述は、コードを介した1つの特定のパスを示すことを知っています。 私の仲間の一人がコメントしました: 単体テストを手動で作成することは、例による証明です。 彼は、Quickcheckのようなツールと型を使用したプログラムの動作を推論する機能を備えたHaskellのバックグラウンドから来ていました。 彼の含意は、あなたのコードがテストされていないこの方法で試されない他の入力の組み合わせがたくさんあるということでした。 私の質問は次のとおりです。手動でユニットテストを記述しているかどうかは、例によって証明されますか?

6
単体テストは「機能的な」ソフトウェアのみを対象とすべきか
新しいソフトウェア開発プロジェクトでStructureMapを使用しています。チームメンバーの1人が、基本的にStructureMapコンテナー構成をテストする単体テストを実装しました。これを行うには、次のようにします。 アプリケーションの名前空間のクラスに構成されているアセンブリのインスタンスの数をカウントします。 クラスレベルで予期されるインスタンスを定義します 予想されるインスタンスが見つかったインスタンスの総数と一致することを表明します。 予想されるインスタンスがテストで定義されたインスタンスと一致することを表明する この例は次のとおりです。 var repositories = container.GetAllInstances<IEnvironmentRepository>(); Assert.AreEqual(1, repositories .Count()); foundInstances = foundInstances + repositories .Count(); 次のクラスの「単体テスト」もあります。 public MyClass(IEnvironmentRepository environmentRepository) { } これらのテストでは、IEnvironmentRepositoryをモックしているため、ライブシステムで発生するようなコンテナーからの注入は行いません。 同僚は、「ユニットテストはそれ自体の構成のみをテストする」というコメントを付けて、structuremap configのユニットテストを無視しました。これは明らかにテストの目的であり、私の意見では完全に有効です。テストを無視した人に構造テストの構成を削除してIEnvironmentRepository(テストはまだ無視されています)、完全な単体テストスイートを実行するように依頼したところ、すべて成功しました。次に、アプリケーションを実行しましたが、コンテナー構成が無効になったため、アプリケーションが倒れました。私の意見では、これはテストの価値を証明しました、私の同僚はまだ反対しました。彼は単に構成をテストするべきではないと述べましたが、これは単体テストの範囲内であると私は思います。 したがって、いくつかの質問があります。 それは有効な単体テストですか?ストラクチャマップが機能するのではなく、コンテナの構成をテストしています(ただし、重複が確認できます) そうでない場合、テストせずに構成を検証するにはどうすればよいですか。誰かが誤って必要なコード行を削除してチェックインしないようにするにはどうすればよいですか? なければならないMyClassユニットテストは、のインスタンスを解決IEnvironmentRepositoryコンテナからとでこれを渡しますか?

1
プロジェクトの非単体テストを管理する方法は?
私は自分のプロジェクトにtestsユニットテストではないコードをいくつか持っています。これらは実行することを意図しており、結果は人間が評価する必要があります。これは、物理エンジンを作成していて、開発中に自分が何をしているかを確認する必要があったためです。それでsimulation、テストモジュールでパッケージを作成しました。シミュレーションはユニットテストライブラリを使用しているため、技術的にはユニットテストですが、実際のユニットテストのようにすべてを実行するわけではありません。 すべての単体テストを簡単に実行したいので、これらの特別なテストを単体テストと区別します。機能テストに少し似ていると思います。アプリケーションを機能テスト用に準備しなければならないケースに遭遇したことがありますか?その機能テストの準備(基本的には私のシミュレーション)はプロジェクトのどこに配置し、ユニットテストとどのように区別するのですか? 私はJavaを使用しているため、すべてのメソッドシグネチャをから@Test public void myNamedTest()に変更できpublic static void main(String[] args)ますが、シミュレーションを使用するのは面倒で実用的ではありません。 プロジェクトで使用junitしていgradleます。で特別なテストフォルダを作成するソリューションgradleは大歓迎です。

2
単体テストで注釈の存在を確認できますか?
抽象クラスとそのN個の拡張によって形成されるJavaクラス階層があります。抽象クラスには、@ Removeアノテーションが付けられたメソッドがあります。このアノテーションが削除されても例外がすぐに失敗することはありませんが、メモリ不足の例外が発生する可能性があるため、このアノテーションがリファクタリングで消えた場合は、できるだけ早く通知するようにしたいと思います。 私はGUTS(優れた単体テスト)を作成しようとしているので、テストでこの「技術要件」を文書化し、それを明記するテストケースを作成できると考えました。 しかし、これは機能ではなく、実装の詳細であり、メソッドの動作にはリンクされていません(メソッドは空である可能性がありますが、存在し、注釈が必要です)。 そのためのテストを作成しても大丈夫ですか、またはこの注釈の存在を確認する他の方法はありますか?

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