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

「TDDについて話すことはほとんど効果がありません。誰かにTDDを説得したい場合は、結果を示してください」と人々は言います。ただし、TDDがなくても、すでにすばらしい結果が得られています。TDDを使用する人が良い結果を得ることが納得できないことを私に示すと、TDDとTDD以外の両方を書く人がTDDでより良い結果を得ることができるようにしたいと思います。 これらすべてにもかかわらず、私はTDDを試してみたいと思っています。しかし、私はこれから何かを得るとは確信していません。それが有用であることが判明した場合、私はそれを私のチームの他のメンバーにプッシュしようとします。 私の主な質問は次のとおりです。コードの正確さを既に証明できる場合、TDDはコードに何らかの目的を果たしますか？ 明らかに、どちらも特効薬ではありません。詳細を逃したために証拠が間違っている可能性があり、テストでは、テストに失敗したバグを特定できない可能性があります。結局、私たちは人間であり、誰もが100％バグのないコードを永遠に作ることはできません。私たちはできるだけ近づくように努力することができます。 しかし、TDDは、その正確性が証明されたコードの時間を実際に節約するでしょうか？つまり、コードが動作するステートマシンで、有効なすべての状態とその範囲が開発者によって認識され、すべてが考慮され、コードがすべての例外を渡すホワイトリストスタイルのエラーチェックで設計されているコード予期しないリークがないことを確認するための上位ハンドラー->（理由内の）関連メッセージをクライアントに表示することも、ログ通知を管理者に送信することもありません。 実際の例での回答の方が良いでしょう。 いくつかの説明： この質問は、コードの正当性を証明できるかどうかについてではありません。デフォルトでは、すべてのコードが妥当な時間枠内で正しいことが証明できるとは限らないが、一部のコードはそうであると想定します。たとえば、FizzBu​​zzモジュールの正当性を証明するのは非常に簡単です。クラウドベースのデータ同期サービスではそれほど簡単ではありません。 この制限内では、質問は次のように尋ねます。コードベースが2つの部分に分割されているという仮定から始めます。[I]正しいことが証明されている部分[II]正しく証明されていないが、手動で動作するようにテストされている部分。 今までTDDプラクティスがなかったこのコードベースにTDDプラクティスを適用したいと思います。質問は次のように質問します。TDDはすべての単一のモジュールに適用する必要がありますか、それとも、正しくないことが証明されたモジュールにのみ適用すれば十分でしょうか。 「実証済み」とは、このモジュールを完全に機能的なスタイルと見なすことができることを意味します。つまり、このモジュールは外部のグローバルまたは外部状態に依存せず、やり取りする他のモジュールが従う必要のあるI / O用の独自のAPIを完全に備えています。 。モジュールの外のコードを変更して「このモジュールを壊す」ことはできません。最悪の場合、コードを誤用して、フォーマットされたエラーメッセージを返す可能性があります。 明らかに、すべてのルールには例外があり、新しいコンパイラバージョンのコンパイラバグはこのモジュールにバグをもたらす可能性がありますが、同じバグがそれをテストしたテストに導入され、意図したとおりに機能しなくなったテストから誤った安全性をもたらす可能性があります。つまり、テストは魔法のようなソリューションではなく、保護の別のレイヤーであり、この質問は、この保護のレイヤーが、正しいことが証明されたモジュールの特定のケースで努力する価値があるかどうかの問題について説明します（それは確かに）でした。

8 tdd 

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

8 unit-testing  tdd 

TDDの背後にあるアイデアと、チームがTDDを使用する方法を把握しようとしています。NUnit + Moqを使用した次のテストケースがあります（メモリで書き込むだけで、サンプルがコンパイルされるとは限りませんが、説明が必要です）。 [Test] public void WhenUserLogsCorrectlyIsRedirectedToLoginCorrectView() { Mock<IUserDatabaseRepository> repoMock = new Mock<IUserDatabaseRepository>(); repoMock.Setup(m => m.GetUser(It.IsAny())).Returns(new User { Name = "Peter" }); Mock<ILoginHelper> loginHelperMock = new Mock<ILoginHelper>(); loginHelperMock.Setup(m => m.Login(It.IsAny(), It.IsAny())).Returns(true); Mock<IViewModelFactory> factoryMock = new Mock<IViewModelFactory>(); factoryMock.Setup(m => m.CreateViewModel()).Returns(new LoginViewModel()); AccountController controller = new AccountController(repoMock.Object, loginHelperMock.Object, factoryMock.Object) var result = …

8 tdd  mocking 

暇なときにゲームのコーディングをしていますが、プログラミングに関しては、まだ初心者です。この質問がトピックから外れている場合や、他の人に役に立たない場合は、申し訳ありませんが、うまくいけば、役に立ちます。 コードの設計や、コーディングのさまざまな方法論やアプローチについての本を読むのに多くの時間を費やしてきました。この調査の過程で、私はテスト駆動開発の概念に出会います。このアイデアを支持する人々は通常、それについて非常に情熱的です。私はそれがソフトウェアを書くスピードと効率を助けることができると信じています。時間は非常に貴重なリソースであるため、プログラミングクラフトの知識を広げようとせずに、何とかやり過ごすのではなく、最善の方法で学ぶことを学びたいと思います。 とにかく、私は初心者だからといって、テスト駆動開発をゲームにどのように適用するか想像できません。この件についていくつかの記事を見つけましたが、あまり役に立ちませんでした。私が見た単体テストの例のほとんどは、非常に単純な定型の例、またはまったくゲームに似ていないソフトウェアの例です。 私自身のコーディングでは、同様の考え方でテスト駆動開発に取り組みますが、実際にはTDDとしての資格はないと確信しています。ゲームに追加する機能を実装するための最小限のコードを記述し、すぐにゲームをテストして、機能するかどうかを確認します。意図したとおりに起こらない場合は、すぐに変更を加えて、自分が望むものに近づけます。機能していないか壊れている場合、およびコードを読み取ってもバグを見つけることができない場合は、予期しない動作が見つかるまでデバッガーのメソッドを順に実行し、それを削除します。私が言おうとしているのは、ほぼすべての増分変更の後で、常にゲームをテストしているということです。テストは私の開発を推進します。「単体テスト」は私の頭の中にあります、 私の実際の質問に移ります。複雑なゲームの単体テストを作成するにはどうすればよいですか？複雑に言うと、ゲームプレイの多くの創発的な側面を意味します。つまり、ゲームプレイの本質は、プレイヤーの選択と組み合わされたゲーム内のさまざまな要素間の相互作用から生まれます。たとえば、手続き型の世界を持つローグライクなRPG。そのようなゲームのためにどんなユニットテストを書くでしょうか？このようなゲームにテスト駆動開発をどのように適用できますか？

8 unit-testing  tdd  game-development  methodology  games 

私は毎日のプログラミングの練習でTDDを採用しようとしています。私は仕事でそれを非常に効果的に使用していますが、いくつかの複雑なアルゴリズムを使用している私の個人的なプロジェクトで問題を抱えています。 この質問をさせる特定のアルゴリズムは、拡張カルマンフィルターです。私が書いたコードに自信が持てないほど複雑ですが、分割するのが難しいほど単純です。 入力と予想される出力を使用してアルゴリズムのテストを作成することもできますが、中間のステップには自信がないため、途中でスラッシングとショットガンコーディングをたくさん行います。 合理的で複雑なアルゴリズムを使用してTDDを使用したことがある場合、アプローチは何ですか。

8 algorithms  tdd 

これはこの質問のフォローアップです。科学的アルゴリズムのライブラリがあるときに、ユニットテストを行う方法を尋ねていました。現在、同様の問題がありますが、プロジェクトが異なります。 私は、DirectX、OpenGl、WebGl、Silverlight、WPFの3Dグラフィックエンジンフレームワークの抽象化に取り組んでいます。シナリオは次のとおりです。このプロジェクトは、同じオフィスで作業している私の同僚の小さなチームによって開発されています。私たちは皆、コンピューターサイエンティストであり、ソフトウェアエンジニアリングコミュニティや実践にはあまり関与していません。SubversionからGitに切り替えて、プロジェクトをCodeplexに公開することを説得するのに苦労しました。プロジェクトは大きくなり（C＃の約80K行）、現在はShader Model 5.0までのほとんどのDirectXとOpenGlをカバーしているため、リンクされた質問で説明されているような1人のプロジェクトではありません。また、オープンソースコミュニティとのコラボレーションを促進したいと考えています。 これまでのところ、すべてのデバイスとリソースの初期化、シーンの設定、描画を含む小さなアプリケーションを作成してテストしてきました。問題は、それを異なるものにする方法がわからない、つまり、リソースの割り当て、プリミティブテセレーション、シェーダーコンパイルなど、フレームワークの特定の機能をテストする小さなテストケースを設計する方法です。エンジン全体の初期化。これらのケースのいくつかでは、便利なモックを考えることができますが、一般的に、出力がビジュアル（イメージ、またはアニメーションシーン）の場合、レンダリングアルゴリズムの正確さをどのようにテストできますか？現在、私たちが考え出した最も賢いことは、同じシーンをソフトウェアレンダラーであるDirectXとOpenGlにレンダリングし、それらをピクセルごとに比較することです。 では、ここでの「正しい」テストアプローチとは何でしょうか。

8 c#  unit-testing  tdd 

CTO / CIOによって設定された開発チームの新しい要件の1つは、テスト駆動型の開発になることですが、開発のライフサイクルを把握していないため、ビジネスの残りの部分は役に立たないと思います。 1つのスプリント内で常に変更されました。これは、10のテストケースを書くことに時間を浪費することに苛立ち、明日は役に立たなくなります。 これらの要件の変更を回避し、開発ライフサイクルについてビジネスを教育するプロセスを設定することを提案しました。ビジネスがアイデアを得られない場合はどうなりますか？あなたならどうしますか？

8 agile  tdd 

テスト駆動開発を使用して最初のプロジェクトを開発しています。Zend FrameworkとPHPUnitを使用しています。 現在、私のプロジェクトは100％のコードカバレッジですが、自分のコードを記述する順序を理解できていません。 私のオブジェクトが何をすることが期待されているかで最初にテストを書くべきですか、それとも私のオブジェクトを書き込んでからそれらをテストするべきですか？ 私はコントローラー/モデルを完成させ、それに対するテストを作成することに取り組んできましたが、これがTDDの目的であるかどうかはわかりません。 何かアドバイス？ たとえば、AuthプラグインとAuthコントローラーを作成し、それらがブラウザーで正しく動作することをテストしました。それから私は座って彼らのためにテストを書き、ブラウザで機能するコードにいくつかの論理エラーがあることを証明しました。

8 tdd 

私はモック/偽のオブジェクトでTDDを実装することを学ぼうとしています。私が持っている質問の1つは、TDDを実装するアプリケーションで依存関係を初期化する方法です。この記事の例 Moq 3でモックを開始すると、次のようになります。 public class OrderWriter { private readonly IFileWriter fileWriter; public OrderWriter(IFileWriter fileWriter) { this.fileWriter = fileWriter; } public void WriteOrder(Order order) { fileWriter.WriteLine(String.Format("{0},{1}", order.OrderId, order.OrderTotal)); } } この例では、コンストラクターがIFileWriterパラメーターを取ります。実際のアプリケーションの場合は実際のファイルライターを、単体テストの場合は偽のファイルライターを提供するためです。私の質問は、実際のアプリケーションでは、誰がこのパラメーターを提供するのですか？このアプリケーションの呼び出し元になると思います。コンストラクタにも依存関係がある場合はどうなりますか？呼び出し元のコードもそれに責任がありますか？ たぶん、より良い方法は、ファクトリーを使用することです。この工場はどのように機能しますか？そして、工場はどのように分配されますか？上記の方法のようにコンストラクターパラメーターにありますか？

8 .net  unit-testing  tdd  dependency-injection  mocking 

私はスクラムとTDDに取り掛かっていますが、いくつかの混乱があると思います。フィードバックについてお聞きしたいと思います。バックログにユーザーストーリーがあり、TDDの一部として開発を開始するために、これまでの要件が必要であるとしましょう。 プロダクトマネージャーとQAがユーザーストーリーを受け入れて受け入れテストに分解する責任を負うべきだと言うのは本当ですか？ 受け入れテストは形式的である必要があるため、上記は正しいと思います。テストとして使用できるだけでなく、製品が要件であることを製品が承認できるように、人間が読める形式でも使用できます。 私が後でこれらの受け入れテストを受けて、それを私の要件として使用すること、つまり、それらが（TDDを介して）実装する一連のユースケースであることも本当ですか？私は混乱をあまり作りすぎていないといいのですが、それが今私が考えている現在の流れです。 更新 当初の意図は不明確だったので、言い換えます。TDDの使用中にユーザーストーリーをコードに変換するスクラムフローの詳細を知りたい。 開始点は明らかです。ユーザーはニーズ（または製品としてのユーザーの代表）を表面化します。これは、既知の形式で1〜2行の短い説明であり、製品のバックログに追加されます。 春の計画会議がある場合、ユーザーストーリーはバックログから取得され、開発者に割り当てられます。 開発者がコードを作成するには、要件が必要です（特に、要件はテストの派生元であるため、TDDで必要です）。 いつ、誰が、どの形式で要件がコンパイルされますか？ 私が頭に浮かんだのは、製品とQAが受け入れテストを介して要件を定義することです（私はFitNesseまたはソートを使用して自動で考えていますが、それは私が考えるコアではありません）同時に2つの目的を果たすのに役立ちます： 彼らは「完了」を適切に定義しています。 それらは、開発者にテストの派生元を提供します。 これらがいつ記述されたかはわかりませんでした（スプリントが選択される前に追加情報が届くか、ストーリーが選択されないため、繰り返しの間に開発者がスタックを待機する可能性があるため、これは無駄になります）。 ..）

8 agile  scrum  tdd  requirements  acceptance-testing 

多くの場合、TDDを使用する利点は「長期的な」利益と見なされます。コード全体がより適切に構造化され、テストが容易になり、全体として顧客から報告されるバグが少なくなります。 しかし、TDDを使用することの短期的なメリットはどこにありますか？実際に弱くて簡単に測定できるものはありますか？ 長期的な利益が測定可能である場合、明らかな（または定量化によっては明らかではない）短期的な利益を得ることが重要ですか？

8 agile  tdd 

私は長い間、TDDスタイルのコードを設計および開発してきました。TDDについて私を悩ませているのは、ビジネスロジックや興味深い動作を含まないコードのテストを作成することです。TDDはテスト以上の設計アクティビティであることは知っていますが、これらのシナリオでテストを記述することは役に立たないと感じることがあります。 たとえば、「ユーザーがチェックボタンをクリックすると、ファイルの有効性をチェックする」という簡単なシナリオがあります。このシナリオでは、通常、以下のようなプレゼンター/コントローラークラスのテストの作成を開始します。 @Test public void when_user_clicks_check_it_should_check_selected_file_validity(){ MediaService service =mock(MediaService); View view =mock(View); when(view.getSelectedFile).thenReturns("c:\\Dir\\file.avi"); MediaController controller =new MediaController(service,view); controller.check(); verify(service).check("c:\\Dir\\file.avi"); } ご覧のとおり、動作を検証するための設計上の決定や興味深いコードはありません。MediaServiceに渡されたビューから値をテストしています。私はいつも書いていますが、この種のテストは好きではありません。これらの状況についてどうしますか？あなたはいつもテストを書いていますか？ 更新： 苦情の後にテスト名とコードを変更しました。一部のユーザーは、このような些細なケースのテストを記述して、将来誰かが興味深い動作を追加する可能性があると述べました。しかし、「今日のコード、明日のデザイン」についてはどうでしょう。？私を含む誰かが将来さらに興味深いコードを追加した場合、そのテストを作成できます。ささいなことでなぜ今やらなければならないのですか？

8 unit-testing  language-agnostic  tdd 

ほとんどのアジャイルメソッドの基本的な要点は、機能が開発され、テストされ、多くの場合リリースされるまで、「完了」しないことです。これは、スクラムプロセスの「スプリント」など、時間の短いターンアラウンドで発生するはずです。 アジャイルの共通部分はTDDでもあり、テストが最初に行われると述べています。 私のチームは、多くの特定の描画などを行うGUIプログラムに取り組んでいます。テストを提供するために、テストチームは、少なくともテストしようとしていることを実行しようとする何かを処理できる必要があります。この問題を回避する方法は見つかりませんでした。 基本的に不可解なインターフェースをターゲットにしたソフトウェアを書こうとした場合、非常に苦労することになるので、それらがどこから来ているのか非常によくわかります。動作はかなり明確に規定されていますが、自動化に関してさまざまなUI要素を操作する正確なプロセスは、機能に固有すぎて、テスターが自動化スクリプトを記述して、存在しないものを駆動することはできません。たとえできたとしても、多くのことが後で仕様から欠落していると判明します。 私たちが行うことを検討したことの1つは、人間が「自動化」できるように、ユースケースの観点から説明した、実行する必要のある一連のステップのようなテスト「スクリプト」をテスターに​​記述させることでした。これは、開発者が機能を作成したり、他の誰かが検証したりすることで実行できます。テスターは後で機会を得たときに、主に回帰の目的で「スクリプト」を自動化します。しかし、これはチームに追いつくことにはなりませんでした。 チームのテスト部分は、実際にはかなりの差で遅れています。これが、人間が実行する「スクリプト」を開発するための明らかに余分な時間が発生しなかった理由の1つです。開発者に追いつくために危機に瀕しています。それらを待っていた場合、何も実行されません。それは本当に彼らのせいではありません、彼らはボトルネックですが、彼らは本来あるべきことをしていて、できるだけ速く働いています。プロセス自体はそれらに対して設定されているようです。 非常に多くの場合、テスターが最終的に確認したバグを修正するために行った作業を1か月以上前に戻す必要があります。私が何かをしたいのは醜い真実です。 では、この失敗のカスケードを解決するために他のチームは何をするのでしょうか？テスターを私たちの前に置いて、どのようにしてスプリントで実行する機能のテストを書いて、その間に親指をいじる必要がないようにすることができますか？現在のところ、アジャイル定義を使用して機能を「完了」させるには、開発者を1週間作業させ、次にテスターを2週間作業させ、開発者が思いついたすべてのバグを修正できるようにする必要があります。過去数日間。それが妥当な解決策であると私が同意したとしても、それは起こりません。より良いアイデアが必要です...

8 agile  testing  development-process  tdd 

仕事中に興味深い協調コーディングの問題に遭遇しました。 私はいくつかのユニット/機能/統合テストを書き、アプリケーションに新しい機能を実装しました。これにより、最大20人の開発者が作業します。すべてのテストに合格し、コードをチェックインしました。翌日、プロジェクトを更新したところ、（偶然に）テストメソッドの一部が他の開発者によって削除されていることに気付きました（開発者側で問題をマージしています）。新しいアプリケーションコードは変更されませんでした。 このような問題を自動的に検出するにはどうすればよいですか？つまり、コードが引き続き機能する（または削除されなかった）ことを自動的にチェックするテストを作成します。テストに対して同じようにするにはどうすればよいですか？ 必要に応じて、Java、JUnit、Selenium、SVN、Hudson CIを使用しています。

8 testing  version-control  unit-testing  tdd  collaboration 

私の同僚は、アジャイル開発に関するセミナーにかつて、ユニットテストを技術文書として使用することが可能だと聞いていました。クラスの使用方法の例として単体テストを使用するようなもの。 Googleのクイック検索でTDDとドキュメントが提供されました。これにより、それが可能であることが証明されます。しかし、コードを見ると、明らかにそのような方法で単体テストを実装できていないことがわかります。 私の意見では、ユニットテストは、モックおよび偽のクラスと関数の助けがあっても、最小限のユニットとしてコードをテストするためにあります。 したがって、質問は次のとおりです。 クラス（またはクラスのセット）の使用方法を示すのは、機能テストのタスクではありませんか？ 単体テストを技術文書として使用できる場合、そのような単体テストの実装方法に関するガイドラインはありますか？

8 agile  unit-testing  documentation  tdd