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

私はTDDにかなり慣れていないので、実装コードの前に来る最初のテストを作成するときに問題があります。実装コードにフレームワークがなければ、私は最初のテストを自由に書くことができますが、Java / OOの問題に対する考え方によって常に汚染されているようです。 たとえば、私のGithub ConwaysGameOfLifeExampleで最初に書いたテスト（rule1_zeroNeighbours）では、まだ実装されていないGameOfLifeオブジェクトを作成することから始めました。存在しないsetメソッド、存在しないstepメソッド、存在しないgetメソッドを呼び出し、アサートを使用しました。 テストはさらにテストを書いてリファクタリングするにつれて進化しましたが、元々は次のようなものでした： @Test public void rule1_zeroNeighbours() { GameOfLife gameOfLife = new GameOfLife(); gameOfLife.set(1, 1, true); gameOfLife.step(); assertEquals(false, gameOfLife.get(1, 1)); } この最初のテストを書くためにこの初期段階でどのように決定したかに基づいて実装の設計を強制していたので、これは奇妙に感じました。 あなたがTDDを理解する方法でこれは大丈夫ですか？私はテストと実装がリファクタリングによって時間とともに進化したという点でTDD / XPの原則に従っているようです。この方法で開始することにより、ソリューション。 TDDは他にどのように使用されますか？GameOfLifeオブジェクトなしで、プリミティブと静的メソッドのみで開始することにより、リファクタリングの反復をさらに行うことができましたが、それはあまりにも不自然に思えます。

15 java  testing  tdd  extreme-programming 

アプリケーション開発の経験はたった2年です。この2年間で、開発に対する私のアプローチは次のようになりました。 要件を分析する Identity Coreコンポーネント/オブジェクト、必要な機能、動作、プロセス、およびそれらの制約 クラスの作成、クラス間の関係、オブジェクトの動作と状態の制約 機能を作成し、要件に従って動作上の制約を使用して処理する アプリケーションを手動でテストする 要件の変更によりコンポーネント/機能が変更された場合、アプリケーションを手動でテストします 最近、TDDを紹介し、開発されたコードが存在する強力な理由があり、展開後の問題の多くが軽減されるため、これは開発を行うのに非常に良い方法であると感じました。 しかし、私の問題は、最初にテストを作成できないことです。むしろ、実際にコンポーネントを作成する前に、コンポーネントを特定し、テストを作成しています。私の質問は 私はそれをやっていますか？そうでない場合は、正確に変更する必要があります 書いたテストで十分かどうかを確認する方法はありますか？ 1 + 1 = 2に相当する可能性のある非常に単純な機能のテストを記述するのは良い習慣ですか、それとも単なるやりすぎですか？ 機能を変更し、それに応じて要件が変更されたかどうかをテストするのは良いですか？

15 programming-practices  unit-testing  tdd  acceptance-testing 

私は巨大なレガシーコードクラスをリファクタリングしています。リファクタリング（私は推測する）はこれを支持します： レガシークラスのテストを書く クラスから一体をリファクタリングする 問題：クラスをリファクタリングしたら、ステップ1のテストを変更する必要があります。たとえば、以前は従来のメソッドにあったものが、代わりに別のクラスになる場合があります。1つの方法でしたが、現在はいくつかの方法である場合があります。レガシークラスの全体像が何か新しいものに抹消される可能性があるため、ステップ1で記述するテストはほとんど無効になります。本質的に、ステップ3を追加します。テストを大量に書き換えます。 リファクタリングの前にテストを書く目的は何ですか？それは自分自身のためにより多くの作品を作成する学術的な運動のように聞こえます。現在、このメソッドのテストを書いていますが、物事をテストする方法と、従来のメソッドがどのように機能するかについて詳しく学んでいます。レガシーコード自体を読むだけでこれを学ぶことができますが、テストを書くことは、その中に鼻をこすりつけることと、別のテストでこの一時的な知識を文書化することにほとんど似ています。したがって、この方法では、コードが何をしているのかを学ぶ以外にほとんど選択肢がありません。私はここで一時的なことを言いました。なぜなら、コードを完全にリファクタリングし、ドキュメントとテストのすべてがかなりの部分で無効になるためです。ただし、私の知識は残り、リファクタリングの新鮮さを保つことができます。 それがリファクタリングの前にテストを書く本当の理由ですか？コードをよりよく理解するのに役立ちますか？別の理由があります！ 説明してください！ 注意： この投稿があります：完全なリファクタリングの時間がないときにレガシーコードのテストを書くことは理にかなっていますか？しかし、「リファクタリングの前にテストを書く」と言いますが、「なぜ」とは言いません。

15 testing  refactoring  tdd  legacy-code 

ソフトウェア開発に対するより伝統的なアプローチとは対照的に、プロジェクトの要件と設計が自動化された受け入れテストと単体テストによって駆動される場合、ソフトウェアプロジェクトに対するリソース計画の全体的な影響を知りたいと思います。 あなたの経験では、「従来の」開発方法論とは対照的に、TDDの下でソフトウェアプロジェクトを完了するためのリソース要件に対する全体的な影響は何ですか？品質が向上し、テストが早期に行われるため不確実性の量が減少することは自明のように思えますが、事前にテストを行う必要があるため、開発者により多くの時間を費やす必要があります。バグを事前に排除することにより、開発の労力はどの程度増加しますか、実際に減少しますか？ 顧客からどれだけの労力が必要ですか？特に前もって大きなデザインに慣れている場合は、プロジェクトとの関係を変える必要がありますか？顧客全体の所要時間は増加しますか、それとも実際に減少しますか？ TDDプロジェクトの開始時の反復TDDプロセスでは、ソフトウェア開発計画がないため、時間の見積もりが非常に曖昧になると思います。たとえば、プロジェクトに20％のポイントがあり、ある程度安定した時間とお金の見積もりを最終的に顧客に提供できるほど信頼性が高まりますか？ 注：ここでは主観的な意見や理論を探しているわけではありませんので、推測しないでください。TDDでの実際の経験をもっと探しています。

15 tdd  estimation 

haskell、scala、ocaml、nemerle、f＃、またはhaXeで記述された静的に型付けされた機能コードを単体テストするのが理にかなっています（最後は本当に興味のあることですが、より大きなコミュニティの知識を活用してください）。 私の理解から： 単体テストの1つの側面は、仕様を実行可能な形式にすることです。ただし、形式化された仕様を言語セマンティクスに直接マップする宣言スタイルを使用する場合、実際に仕様を実行可能な形式で別の方法で表現することもできますか？ 単体テストのより明白な側面は、静的分析では明らかにできないエラーを追跡することです。型安全機能コードは、静的アナライザーが理解するものに非常に近いコードを作成するための優れたツールであることを考えると、多くの安全性を静的分析にシフトできるように思われます。ただし、コードxでy（両方とも座標）の代わりに使用するような単純なミスはカバーできません。OTOHこのような間違いは、テストコードの作成中にも発生する可能性があるため、努力する価値があるかどうかはわかりません。 ユニットテストでは冗長性が導入されます。つまり、要件が変更された場合、それらを実装するコードとこのコードをカバーするテストの両方を変更する必要があります。もちろん、このオーバーヘッドはほぼ一定であるため、実際には問題ではないと主張することができます。実際、Rubyのような言語では実際には利点と比較されませんが、静的に型指定された関数型プログラミングが地上ユニットテストの多くを対象としていることを考えると、ペナルティなしで単純に削減できる一定のオーバーヘッドのように感じます。 このことから、このプログラミングスタイルでは単体テストはやや時代遅れであると推測します。もちろん、そのような主張は宗教的な戦争につながる可能性があるため、簡単な質問に要約します。 このようなプログラミングスタイルを使用する場合、単体テストをどの程度使用し、その理由は何ですか（コードでどの程度の品質を得たいと考えていますか）。または、逆に、静的アナライザーでカバーされているため、ユニットテストのカバレッジを必要とせずに、静的に型指定された機能コードのユニットを修飾できる基準はありますか？

15 unit-testing  functional-programming  tdd  haskell  scala 

Code Retreatは、ソフトウェア開発の基礎に焦点を当てた終日トレーニングイベントです。「グローバルな」コードリトリート日が近づいています。私はそれを楽しみにしています。とは言うものの、私は以前に1つに行ったことがあり、膨大な量の混乱があったと言わざるを得ません...それは問題ありません。 私がまだ理解していないことの1つは、「ゲームオブライフ」がTDDにとって良い問題である理由と、TDDの良い点と悪い点がどのように感じられるかということです。 これはかなり開かれた質問であることに気づきますので、気軽にコメントしてください。

15 tdd 

非常に多くの異なるパスをたどることができるAIのようなシステム、または実際に複数の異なる入力を持つ任意のアルゴリズムを作成する場合、可能な結果セットには多数の順列が含まれることがあります。 結果の多くの異なる順列を出力するシステムを作成するときに、TDDを使用するにはどのようなアプローチをとるべきですか？

15 testing  algorithms  tdd  artificial-intelligence 

私は最近、モックオブジェクトがしばしば誤解され、誤用されると言った記事を読みました。私が注目できる明確なモッキングアンチパターンはありますか？

15 testing  tdd  anti-patterns  object-oriented-design  mocking 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 WebアプリケーションにTDDを実装して、リグレッションを減らし、リリースの品質を向上させたいと思いますが、Webアプリケーションのようにふわふわしたもので自動化されたテストをどれだけうまく実行できるか確信がありません。 TDDと単体テストについて読んで試しましたが、例は「堅実」で、通貨コンバーターなどの単純な機能です。 コンテンツ管理および公開システムの単体テストに役立つリソースはありますか？ショッピングカート/ストア（物理製品およびオンライン製品）の単体テストはどうですか？AJAX？ 「Web Test Driven Development」のグーグル検索では、数年前の古い記事で、計算機のような機能の同じ例や、TDDが何よりも優れている理由（例なし）について説明しています。

15 web-development  unit-testing  web-applications  tdd 

TDDは、テストによって導かれるコードの設計に関するものです。 したがって、通常、典型的なレイヤーは事前に構築されていません。それらはリファクタリング手順でわずかに表示されるはずです。 ドメイン駆動型設計には、アプリケーション層、インフラストラクチャ層、ドメイン層、永続層などの十分に確立された層を定義する多くの技術的パターンが含まれます。 DDDプロジェクトのコーディング部分をゼロから開始するには、どのように動作するのですか？ DDDの技術的なパターンに適合するために、設計をテストから厳密に浮かび上がらせる必要がありますか？ または、それらの空のレイヤー（アプリケーション、エンティティ/ドメインサービス、インフラストラクチャ）を作成し、TDDをそれぞれに個別に適合させる必要があります（モックを使用してレイヤー間を分離します）。

15 architecture  testing  tdd  domain-driven-design 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 チームでTDDを使用しているのは私だけです。どうすればそれを使用することができますか？ 私が引っ張ると、誰かのコードが私のテストを壊してしまい、私がそれらを修正しなければならないのがイライラしています。 github、fork、およびpullリクエストを使用してこの問題を解決し、プルが受け入れられる前にテストに合格する必要がありますか？ 私はプロジェクトマネージャーではなく、彼女にそれを使用するよう説得することはできないようです。

15 tdd  ruby-on-rails  communication 

TDDの実務者から、TDDの利点の1つは開発者にSOLID原則（単一責任、オープンクローズ、Liskov置換、インターフェイス分離、依存関係反転）を強制することであると多くのことを聞きます。しかし、私にとっては、いくつかのテスト（主に単体テスト）を記述するだけで十分であり、SOLIDに従うことが重要です（したがって、テスト可能なアーキテクチャを作成します）。 TDDは、開発者に単体テストを書くよりも積極的にSOLIDをフォローするように強制しますか？

15 unit-testing  tdd  solid 

バグを修正するには、コードのセクションを削除する必要がある場合があります。TDDの純粋主義者は、失敗したテストを記述し、コードを削除して、テストの合格を監視することを推奨します（と思います）。 さて、いくつかのコードが削除されたと断言するテストがあるのは本当に奇妙に思えます。確かに、誰もソース管理を掘り下げてそのコードを元に戻すことはないでしょうが、それだけの価値はありますか？それが価値がある場合、追加されたコードのテストを書くよりも価値が低いように見えますよね？

14 unit-testing  tdd  bug 

コミットごとにテストを実行する継続的な統合を行う場合、一般的なベストプラクティスは、すべてのテストを常にパスすることです（「ビルドを中断しないでください」）。 私はそれに関するいくつかの問題を見つけます： たとえば、チケットに対応するテストを作成して、オープンソースプロジェクトを支援することはできません。失敗したテストを含むオープンソースプロジェクトにプルリクエストを提案した場合、ビルドは失敗としてマークされ、プロジェクトは「ビルドを壊す」ためリポジトリにマージされたくないでしょう。 そして、レポでテストに失敗するのは悪いことではないと思います。それは、トラッカーに未解決の問題があるようなものです。これらは修正されるのを待っているものです。 同じことが会社にも言えます。TDDを使用している場合、テストを作成し、コミットしてから、テストを満たすロジックコードを作成することはできません。つまり、ラップトップで4〜5個のテストを書いた場合、休日に行く前にテストをコミットすることはできません。誰も私の仕事を取り戻すことはできません。たとえばメールで送信する場合を除き、同僚と「共有」することさえできません。また、テストの作成者とモデルの作成者との作業も妨げられます。 言うまでもなく、私はビルドプロセスを誤用/誤解しているか、継続的な統合を行っていますか？「通過する」/「通過しない」という指標は狭すぎるように思えます。 継続的な統合とTDD互換性を実現する方法はありますか？ 「新しいテスト」（失敗する可能性がある）と「回帰テスト」（以前は機能していたため失敗するべきではない）を区別するための標準的なソリューション/プラクティスがあるかもしれません。

14 tdd  continuous-integration  tests 

私はプロのプログラマーですが、ソフトウェアエンジニアリングの正式なトレーニングを受けたことはありません。私は頻繁にここを訪れているので、可能な限りユニットテストを書く傾向に気づきました。私のソフトウェアがより複雑で洗練されているので、デバッグを支援するための自動化されたテストをお勧めします。 ただし、私の仕事のほとんどは、複雑なSQLを作成してから、何らかの方法で出力を処理することです。たとえば、SQLが正しいデータを返していることを確認するテストをどのように作成しますか？次に、データが制御されていなかった場合（たとえば、サードパーティシステムのデータ）、ダミーデータの連を手書きせずに処理ルーチンを効率的にテストするにはどうすればよいでしょうか。 私が考えることができる最良の解決策は、一緒にほとんどの場合をカバーするデータのビューを作成することです。次に、これらのビューをSQLに結合して、正しいレコードを返しているかどうかを確認し、ビューを手動で処理して、関数などが意図したとおりに動作しているかどうかを確認します。それでも、それは過度で薄汚いようです。特にテストするデータを見つける...

14 database  sql  tdd  test-automation