タグ付けされた質問 「tdd」

TDDは、テスト駆動開発またはテスト駆動設計の略です。Red-Green-Refactorサイクルとして知られている、それを満たすためにコードを書く前に単体テストを書く習慣です。

5
TDDに従うことは必然的にDIにつながりますか?
テスト駆動開発(TDD)、依存性注入(DI)、および制御の反転(IoC)をすべて同時に行うことを学びました。TDDを使用してコードを記述するとき、クラスのコンストラクターで常にDIを使用します。これは、TDDをどのように学んだかによるものなのか、それともTDDの自然な副作用なのか疑問に思っています。 だから私の質問は次のとおりです:TDDプリンシパルに従って、外部サービスに依存しない単体テストを書くことは必然的にDIにつながりますか?

9
TDD:私はそれを正しくやっていますか?
私は新しいプログラマーです(約1年しか学んでいません)。それをより良くするという目標で、最近TDDについて学びました。非常に役立つと思われるため、私はそれを使用する習慣を身に付けたかったのです。正しく使用していることを確認して確認したかったのです。 私がやっていること: 私が必要とする新しい方法を考えてください。 そのメソッドのテストを作成します。 テストに失敗します。 書き込み方法。 テストに合格。 メソッドをリファクタリングします。 繰り返す。 私が書いたすべての方法でこれをやっていますが、気にするべきではないものがありますか?後で、私は通常、既存のメソッドを別の方法または状況でテストする方法を考えます。私が考えているこれらの新しいテストを作成する必要がありますか、または各メソッドがすでに独自のテストを持っているので、気にする必要はありませんか?コードをテストしすぎることはできますか? 編集 また、これは私がただ疑問に思っていたものでした。GUIの作成などを行う場合、そのような状況ではTDDが必要ですか?個人的には、そのためのテストをどのように書くか考えられません。
14 tdd 

3
ユニットテストの直交性対ユニットテストの簡潔さ
ビデオゲームのステアリングシステムの単体テストを書いています。システムにはいくつかの動作があります(理由Aのためにこの領域を避け、理由Bのためにこの領域を避けてください。それぞれが領域のマップに少しのコンテキストを追加します。 動作の単体テストの書き方を決めるのに苦労しています。TDDが示唆しているように、私はその振る舞いが望ましい動きにどのように影響するかだけに興味があります。たとえば、avoid-because-of-reason-Aは、悪い位置を示唆する位置からの移動をもたらすはずです。実際には、ビヘイビアーがマップにコンテキストを追加する方法や理由は気にしません。目的の動きが位置から離れているだけです。 したがって、各動作のテストでは、動作を設定し、マップに書き込むようにし、マップ解析関数を実行して目的の動作を実現します。その動きが私の仕様を満たしているなら、私は幸せです。 ただし、現在のテストは、正しく動作する動作と、正しく機能するマップ解析機能の両方に依存しています。解析機能が失敗した場合、数回ではなく数百回のテストに失敗します。多くのテスト作成ガイドは、これが悪い考えであることを示唆しています。 ただし、マップをモックアウトすることで動作の出力に対して直接テストする場合、確実に実装に緊密に結合していますか?わずかに異なる動作を使用して、マップから同じ目的の動きを取得できる場合、テストは合格します。 だから今、私は認知的不協和音に苦しんでいます。これらのテストを構成する最良の方法は何ですか?
14 tdd  unit-testing 

6
TDDが開発の品質や速度を改善した方法のケーススタディを探しています[非公開]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新することがありますので、上のトピックソフトウェア工学スタックExchange用。 6年前に閉鎖されました。 私の会社では、なぜTDDを行うべきなのかを主張しようとしています。現在、ほとんどの開発者はプロジェクトを完了させるためにできる限りのことを行ってから、マネージャーの指標を満たすために事後に単体テストを追加します。TDDを実施し、利益を確認している評判の良い企業の例は大歓迎です。
14 tdd 

4
モックオブジェクトはいつ使用する必要がありますか?
TDDについて多くのことを読みましたが、まだ疑問があります。たとえば、次のクラス図があります。 これは、TDDとモックオブジェクトについて学ぶための簡単な例です。 どのテストを最初に書くべきですか?製品、次にライン、最後に注文?その場合、ラインと製品を使用して注文をテストする必要がありますか、またはモックオブジェクトを使用する必要がありますか?モックオブジェクトはいつ使用する必要がありますか?XPおよびTDDでUMLを使用する必要がありますか? 私はまだこれらのものを得ていません。

3
バッチ処理のTDD:実行方法
RoRなどの「赤/緑/リファクタリング」などは問題ありません。 私の仕事は、Pythonや他のカスタムツールでサードパーティからの非常に大きなファイルをバッチ処理することです。 これらのファイルの属性に対するチャーンは高いため、かなり頻繁に適用される多くの修正/拡張機能があります。 期待される結果を備えた既知のテストデータによる回帰テストは存在しません。最新のテストケースが手作業でコーディングされた最後のバッチに対して最も近いものが実行され、爆発しないことを確認してから、スポットチェックと統計テストを適用して、データがまだ正常に見えるかどうかを確認します。 Q >> TDDの原則をこのような環境に取り入れるにはどうすればよいですか?
14 testing  tdd 

4
再設計時にテストを効率的に機能させるにはどうすればよいですか?
十分にテストされたコードベースには多くの利点がありますが、システムの特定の側面をテストすると、ある種の変更に耐えるコードベースが得られます。 例は、特定の出力(テキストまたはHTMLなど)のテストです。多くの場合、テストは、特定のテキストブロックを一部の入力パラメーターの出力として期待するため、またはブロック内の特定のセクションを検索するために(単純に?)書き込まれます。 新しい要件を満たすため、またはユーザビリティテストがインターフェイスの変更をもたらしたため、コードの動作を変更するには、テストも変更する必要があります。おそらく、変更されるコードの具体的な単体テストではないテストでさえもです。 これらのテストを見つけて書き換える作業をどのように管理しますか?「すべてを実行して、フレームワークでそれらを整理する」ことができない場合はどうでしょうか。 他にどのようなテスト対象コードが習慣的に脆弱なテストになりますか?

1
画像処理コードを単体テストする方法は?
私は画像処理(主にOCR)に取り組んでおり、開発に単体テストをどのように統合すべきか疑問に思っています。 私はすでに、より一般的なタイプのコードに対して単体テストを使用していますが、画像処理コードを処理するとき、その処理方法がわかりません。この種のコードには常に画像データの入出力が必要であり、これを模倣することは明らかではありません。今のところ、主に統合テストを行っていますが、実行には時間がかかります。この種のコードをユニットテストに分割して、より迅速に実行できるようにするためのアイデアが欲しいです。 編集:キャラクターの分析は、複数の回転、スケーリング、および形態学的操作を含む多くのステップを経ることができます。これらの手順は、アルゴリズムの開発中に頻繁に変更されます。したがって、テスト中に入力と期待される出力は大きく変化する可能性があります。各文字は100x100ピクセルにすることができるため、コード内でハードコーディングしたり、生成されたデータを操作したりするのは問題ありません。

3
実装の詳細に結合しない単体テストの動作
彼の講演TDDでは、それがすべてうまくいかなかったので、Ian CooperはTDDのユニットテストの背後にあるケントベックの当初の意図をプッシュし(特にクラスのメソッドではなく、動作をテストするため)、テストを実装に結合しないように主張しています。 save X to some data source典型的なサービスとリポジトリのセットを備えたシステムのような動作の場合、テストを実装の詳細に結合することなく、特定のメソッドの呼び出しなど、リポジトリを介してサービスレベルで一部のデータの保存を単体テストする方法)?この種のカップリングを避けることは、実際には努力する価値がない/何らかの形で悪いですか?

4
修正された後にのみテストできるバグをTDDするにはどうすればよいですか?
次に例を示します。私のWebアプリケーションには、ドラッグ可能な要素が含まれています。要素をドラッグすると、ブラウザは「ゴーストイメージ」を生成します。ドラッグするときに「ゴーストイメージ」を削除したいので、この動作のテストを作成します。 私の問題は、最初にこのバグを修正する方法がわからないことであり、テストを書く唯一の方法は修正した後です。 などの単純な関数ではlet sum = (a, b) => a - b、コードを記述する前に、なぜsum(1, 2)等しくないかに関するテストを書くことができ3ます。 私が説明しているケースでは、検証が何であるかわからないので、テストできません(アサーションがどうあるべきかわかりません)。 説明されている問題の解決策は次のとおりです。 let dataTransfer = e.dataTransfer let canvas = document.createElement('canvas'); canvas.style.opacity = '0'; canvas.style.position = 'absolute'; canvas.style.top = '-1000px'; dataTransfer.effectAllowed = 'none'; document.body.appendChild(canvas); dataTransfer.setDragImage(canvas, 0, 0); これが解決策だとは知らなかった。ソリューションをオンラインで見つけた後、テストを作成することさえできませんでした。実際に機能するかどうかを知ることができる唯一の方法は、このコードをコードベースに追加し、目的の効果があったかどうかをブラウザで確認することでした テストは、TDDに反するコードの後に​​記述する必要がありました。 この問題に対するTDDアプローチはどうなりますか?コードの前にテストを書くことは必須ですか、それともオプションですか?

1
TDD方法論をトップダウンで適用できますか?
方法論であるTDDが次のケースをどのように処理するかはわかりません。Pythonでmergesortアルゴリズムを実装するとします。私は書くことから始めます assert mergesort([]) === [] そしてテストは失敗します NameError:名前 'mergesort'は定義されていません 次に追加します def mergesort(a): return [] テストに合格しました。次に追加します assert mergesort[5] == 5 そして私のテストは失敗します AssertionError 私はパスします def mergesort(a): if not a: return [] else: return a 次に、追加します assert mergesort([10, 30, 20]) == [10, 20, 30] そして今、私はこの合格を試みなければなりません。mergesortアルゴリズムを「知っている」ので、次のように記述します。 def mergesort(a): if not a: return [] else: left, …
13 tdd 

3
Given When Then(GWT)とArrange Act Assert(AAA)の違いは?
TDDには、アレンジアサート(AAA)構文があります。 [Test] public void Test_ReturnItemForRefund_ReturnsStockOfBlackSweatersAsTwo_WhenOneInStockAndOneIsReturned() { //Arrange ShopStock shopStock = new ShopStock(); Item blackSweater = new Item("ID: 25"); shopStock.AddStock(blackSweater); int expectedResult = 2; Item blackSweaterToReturn = new Item("ID: 25"); //Act shopStock.ReturnItemForRefund(blackSweaterToReturn); int actualResult = shopStock.GetStock("ID: 25"); //Assert Assert.AreEqual(expectedResult, actualResult); } BDDの記述テストでは、同様の構造を使用しますが、Given When Then(GWT)構文を使用します。 [Given(@"a customer previously bought a black sweater …
13 c#  unit-testing  tdd  bdd 

1
ゲームのテスト戦略
Webベースの教育用ゲームを継承しました。過去1年間、コードの安定化と新しい機能の追加に取り組んできました。ほとんどのロジックはフロントエンドにあるため、バックエンドの単体テストは有用ですが、コードのごく一部をカバーします。 ゲームは複雑になり始めています。各ゲームには2つの異なるモードがあり、モードによってゲームの動作は異なります。ゲームのプレイに影響するさまざまなフラグもあります。 私はもう10年以上アプリケーション開発者であり、これは私を困惑させます。企業の世界では、アルゴリズムは常に同じように機能します。アルゴリズムの単体テストを作成します。値42を期待し、その値を取得しないとエラーになります。 ゲームに関しては、私は迷っています。それらをテストするにはどうすればよいですか?テスターを利用できます。単体テストの作成に時間を費やすことができます。 テスターは...信頼できません。それらは問題を根絶するのに最適ではなく、私はそれらに最善の方向性を与えていません。リリースサイクルごとに膨大な時間を費やしてゲームのあらゆる組み合わせや組み合わせをテストするのではなく、それらをリソースとしてどのように使用すればよいですか? 単体テストは制限されているようです。ほとんどのロジックはjavascript(およびスパゲッティコードを継承)であるため、CucumberやSeleniumなどのフロントエンドスイートを使用して、特定の機能が動作することを確認できます。 それが最善の戦略ですか?ゲーム会社はどのようにゲームをテストしますか? 「複雑なゲームのテスト駆動開発」という質問(サイト上の他の記事も参照)を読みましたが、探しているものには対応していません。テスト方法の具体的な例ではなく、戦略を求めています。

5
有用性に基づいた単体テストの種類
価値の観点から、私は実際にユニットテストの2つのグループを見ています: 自明でないロジックをテストするテスト。それらを(実装前または実装後のいずれかで)記述すると、いくつかの問題/潜在的なバグが明らかになり、将来ロジックが変更された場合に備えて自信を持てるようになります。 非常に簡単なロジックをテストするテスト。これらのテストは、テストよりもドキュメントコード(通常はモックを使用)に似ています。これらのテストのメンテナンスワークフローは、「一部のロジックが変更され、テストが赤になりました-このテストを作成した神に感謝します」ではなく、「一部の些細なコードが変更され、テストが偽陰性になりました-利益を得ることなくテストを維持(書き換え)する必要があります」 。ほとんどの場合、これらのテストは維持する価値がありません(宗教上の理由を除く)。そして、多くのシステムでの私の経験によると、これらのテストはすべてのテストの80%に相当します。 私は他の人が値によるユニットテストの分離のトピックでどう思うか、それが私の分離にどのように対応するかを見つけようとしています。しかし、私が主に目にしているのは、フルタイムのTDDプロパガンダか、テストは役に立たず、ただ書くだけのコードプロパガンダです。途中で何かに興味があります。あなた自身の考えや記事/論文/本への言及を歓迎します。
13 unit-testing  tdd 

2
テスト対象のシステムからクラスを抽出するときに、ユニットテストをリファクタリングする必要がありますか?
いくつかのことを行うこのクラスを作成しました(おそらくこれは単一責任原則の違反です)。私はプロジェクトのいくつかの他の部分が必要であることを今実感作品そのロジックのを、私はそれを公開するつもりだ方法は、私のオリジナルテスト対象システムのうち、クラスを抽出することです。 テストコードを変更せずにこれを行うことができると予想していますが、完了したら、テストはユニットテストではなくなったと主張できます。元のクラスと抽出したクラスをテストします。つまり、テストケースは1つですが、テスト対象のシステムは2つになります。 完了したら、テストコードをリファクタリングすることになっていますか?IE:ExtractedClassTestを作成し、関連するすべてのテストをOriginalClassTestからそこに移動しますか?これは少しリスクが高いようです:プロセスのカバレッジを失う可能性があります。テストを移動するほど簡単ではないかもしれません。等 一方、OriginalClassTestをそのままにしておくと、これがテストメンテナンスの問題であることがわかります。ExtractedClassのテストがどこにあるかを見つけるのは少し混乱するでしょう。あなたの第一印象は、それが存在しないということです。量産コードのリファクタリングが多くなると、これは深刻な問題になる可能性があります。 私はTDDが初めてなので、専門家のアドバイスをお願いします。ありがとう!

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