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

仕事中、私のプロジェクトの1つは主に外部クライアントから渡されたデータを取得し、データベースに保持することです。JPAを使用するJavaエンタープライズアプリであり、ほとんどのロジックはCRUD操作を中心に展開します。 バグの大部分は、何らかの形でJPAに関係しています。 例1：[保存]ボタンを2回クリックすると、JPAは同じエンティティをデータベースに2回挿入しようとし、主キー違反が発生する場合があります。 例2：データベースからエンティティを取得し、編集して、そのデータを更新しようとします。JPAは、古いインスタンスを更新する代わりに、新しいインスタンスを作成しようとする場合があります。 多くの場合、ソリューションはJPAアノテーションを追加/削除/変更する必要があります。また、DAOロジックの変更に関係する場合もあります。 単体テストとTDDを使用してコードに自信を持たせる方法がわかりません。ユニットテストとTDDの適合性が悪いのか、問題に近づいているのかがわかりません。 単体テストは、実行時にしかこれらの問題を発見できず、問題を再現するためにアプリサーバーに展開する必要があるため、不適切なように見えます。通常、データベースは関与する必要がありますが、これは単体テストの定義の外側にあると考えられます。これらは統合テストです。 TDDは、展開とテストのフィードバックループが非常に遅いため、非常に非生産的であるため、不適切なように思われます。deploy + testフィードバックループには3分以上かかります。これは、作成中のコードに関するテストを具体的に実行した場合にのみ発生します。すべての統合テストを実行するには、30分以上かかります。 この型の外側にはコードがあり、できる限りいつでも単体テストを行っています。しかし、バグの大部分と最大のタイムシンクは、常にJPAまたはデータベースに関係しています。 同様の別の質問がありますが、アドバイスに従えば、コードの最も不安定な部分（JPA）をラップし、それ以外のすべてをテストします。私の質問の文脈では、私は同じ悪い状況にいるでしょう。JPAをラップした後の次のステップは何ですか？IMOその質問は（おそらく）私の質問に答えるためのステップですが、それに対する答えではありません。

22 java  unit-testing  tdd  jpa 

私は中規模企業のソフトウェアエンジニアです。TeamCityで実行されるかなり堅牢なテストプラットフォームがあります。すべてのチェックインで単体テストを実行し、毎日の単体テスト/ BVTを実行します。 問題は、大量の単体テストが失敗していることです。 ユニットテストが絶えず壊れていて、メンテナンスされていない場合、かなり頻繁にユニットテストの無意味さを引き出します。変更によってリグレッションが発生したかどうかを確認できないと、単体テストプラットフォームの価値のほとんどが失われます。 良い習慣の文化を作り出す種を植えたいです。壊れたときにテストを修正し、それらを価値あるものとみなし、他の作業とともにテストの修正を優先します。 私は賄ber（焼き菓子！）を試みましたが、単純に尋ねて、チームリーダーに話しました。誰もがそれは良いアイデアだと言いますが、私はそれについて何かをしている唯一の人であると思います。 他の人にテストの修正を奨励し、スプリント内でのテスト修正の優先順位付けを開始する最良の方法は何ですか？ これを尋ねる主観的な方法がなければ、どんなヒントでも喜んで受け入れます。

22 testing  unit-testing  tdd  culture  leadership 

リストで期待されていることを関数が実行することをテストしています。だから私はテストしたい f(null) -> null f(empty) -> empty f(list with one element) -> list with one element f(list with 2+ elements) -> list with the same number of elements, doing what expected そうするために、最善のアプローチは何ですか？ 「WorksAsExpected」という名前で、同じ（メソッド）テストですべてのケースをテストする 各ケースに1つのテストを配置し、こうして 「WorksAsExpectedWhenNull」 「WorksAsExpectedWhenEmpty」 「WorksAsExpectedWhenSingleElement」 「WorksAsExpectedWhenMoreElements」 私が考えていなかった別の選択肢:-)

21 unit-testing  tdd 

ロジックを正しく実装した後でもテストが失敗する場合（テストに間違いがあるため）、TDDでの最善のアクションは何ですか？ たとえば、次の関数を開発するとします。 int add(int a, int b) { return a + b; } 次の手順で開発するとします。 テストの書き込み（まだ機能なし）： // test1 Assert.assertEquals(5, add(2, 3)); コンパイルエラーが発生します。 ダミー関数の実装を作成します。 int add(int a, int b) { return 5; } 結果：test1合格。 別のテストケースを追加します。 // test2 -- notice the wrong expected value (should be 11)! Assert.assertEquals(12, add(5, 6)); 結果：test2失敗しますが、test1成功します。 実際の実装を書く： int …

21 tdd  mistakes 

いくつかのHadoop Webサービスを呼び出すクラスをテストしようとしています。コードはほぼ次の形式です。 method() { ...use Jersey client to create WebResource... ...make request... ...do something with response... } たとえば、ディレクトリ作成メソッド、フォルダ作成メソッドなどがあります。 コードが私が制御できない外部Webサービスを処理していることを考えると、これをどのように単体テストできますか？Webサービスのクライアント/レスポンスをモックすることはできましたが、最近見た「所有していないオブジェクトをモックしないでください」というガイドラインに違反しています。ダミーのWebサービス実装をセットアップできます。それでも「単体テスト」を構成できますか、それとも統合テストになりますか？この低いレベルで単体テストを実行することはできませんか？TDD実践者はどのようにこれに取り組むのでしょうか？

21 unit-testing  tdd  web-services  integration-tests 

私はTDDの意味でのユニットテストについて話している。（自動化された「統合」ではなく、テストと呼ぶのが好きです。） レガシーコード：（C ++）テストなしのコード。（参照：マイケルフェザーズのレガシーコードでの効果的な作業） しかし、次のようなレガシーコード：私たちのチームが過去10〜5年間作業してきたコードです。そのため、何かを変更するためにどこに置くべきかについて非常によく考えています。 私たちは何のために（Boost.Test経由）の場所でのユニットテスト持ち、いくつかの後に来たか、ユニットテストのための「自然な」フィットされているモジュール（一般的なアプリの特定のコンテナ、文字列のもの、ネットワークヘルパーなど） 適切な自動受け入れテストはまだありません。 さて、最近、3つの新しいユーザー向け機能を実装する「喜び」がありました。 それらのそれぞれは、私が変更するのに必要なコード部分に慣れるのに約1〜2時間、変更するのに必要な（小さな）コードを実装するのに1〜2時間、そしてアプリを確認するのにさらに1〜2時間かかりましたその後正しく実行され、実行するはずでした。 今、私は本当に小さなコードを追加しました。（各機能に対して1つのメソッドといくつかの呼び出し行があると思います。） このコードを（WEwLCで提案されている方法のいずれかを介して）除外するので、単体テストが理にかなっている（完全なトートロジーではない）ために、さらに2〜4時間は簡単にかかっていました。これにより、各機能に50％〜100％の時間が追加され、すぐにメリットは得られません。 コードについて何かを理解するのに単体テストは必要ありませんでした コードがアプリの他の部分に正しく統合されているかどうかをテストする必要があるため、手動テストは同じ量の作業です。 確かに、あれば、後に、「誰かが」に沿って来て、そのコードに触れ、彼は理論的には、そのユニットテストからいくつかの利点を持つことができます。（テストされたコードの島はテストされていないコードの海に住んでいるので、理論的にのみ。） したがって、「今回」は、ユニットテストを追加するというハードワークを行わないことを選択しました。テスト対象のものを取得するためのコード変更は、機能を正しく（そしてクリーンに）実装するためのコード変更よりもはるかに複雑でした。 これは、強く結合されたレガシーコードの典型的なものですか？私は怠け者ですか/チームとして間違った優先順位を設定していますか？または、オーバーヘッドが高すぎないものだけをテストするのが賢明ですか？

21 c++  tdd  legacy  unit-testing 

TDDに関するテキストでは、リファクタリングのステップ中に「重複の削除」または「読みやすさの向上」についてよく読みます。しかし、未使用の関数を削除する理由は何ですか？ たとえばC、メソッドa()とを持つクラスがあるとしましょうb()。今私はそれにf()追いやられる方法を持つことが良いと思うC。実際、定義/記述された単体テストを除くf()すべての呼び出しを置き換えます。これはもう必要ありません-テストを除いて。b()b() 削除してb()、それを使用したすべてのテストを削除するだけでいいですか？その部分は「読みやすさの改善」ですか？

20 unit-testing  refactoring  tdd  readability 

バックグラウンド テスト駆動開発は、私がすでに学校を卒業した後、業界で普及しました。私はそれを学ぼうとしていますが、いくつかの大きな事柄がまだ私を逃れています。TDDの支持者は、次のような多くのことを言います（以降、「単一アサーション原則」またはSAPと呼びます）。 しばらくの間、TDDテストを可能な限りシンプルで表現力豊かでエレガントにする方法について考えてきました。この記事では、テストをできる限り単純かつ分解したものにすることについて、各テストで単一のアサーションを目指して少し探ります。 ソース：http : //www.artima.com/weblogs/viewpost.jsp?thread=35578 彼らはまた、このようなことを言います（以下「プライベートメソッドの原則」またはPMPと呼ばれます）： 通常、プライベートメソッドを直接単体テストすることはありません。これらはプライベートなので、実装の詳細と考えてください。誰もそれらのいずれかを呼び出して、特定の方法で動作することを期待することはありません。 代わりに、パブリックインターフェイスをテストする必要があります。プライベートメソッドを呼び出すメソッドが期待どおりに機能している場合、拡張機能によってプライベートメソッドが正常に機能していると想定します。 ソース：プライベートメソッドを単体テストする方法 状況 ステートフルデータ処理システムをテストしようとしています。システムは、データを受け取る前の状態を考えると、まったく同じデータに対して異なることを行うことができます。システムに状態を​​構築し、特定のメソッドがテストすることを意図した動作をテストする簡単なテストを検討してください。 SAPは、「状態ビルドアッププロシージャ」をテストするべきではないことを提案します。状態はビルドアップコードから予想されるものであると想定し、テストしようとしている1つの状態変化をテストします。 PMPは、この「状態構築」ステップをスキップして、その機能を独立して制御するメソッドをテストすることはできないことを示唆しています。 私の実際のコードの結果は、肥大化し、複雑で、長く、書くのが難しいテストです。状態遷移が変更された場合、テストを変更する必要があります...これは、小さく効率的なテストでは問題ありませんが、これらの長い肥大したテストとは非常に時間がかかり、混乱を招きます。これは通常どのように行われますか？

20 design  unit-testing  tdd 

TDDアプローチを使用することを自分で学びたいと思っていたので、しばらくの間、やりたいプロジェクトがありました。大規模なプロジェクトではなかったので、TDDの良い候補になると思いました。しかし、何かがおかしくなったように感じます。例を挙げましょう： 高レベルでは、私のプロジェクトはMicrosoft OneNoteのアドインであり、プロジェクトをより簡単に追跡および管理できます。また、いつか自分のカスタムストレージとバックエンドを構築することにした場合に備えて、このためのビジネスロジックをOneNoteから可能な限り切り離したままにしておきたいと考えました。 最初に、基本的な平易な言葉の受け入れテストから始めて、最初の機能で何をしたいかを概説しました。これは次のようなものです（簡潔にするために説明を省略しています）。 ユーザーがプロジェクトの作成をクリックします プロジェクトのタイトルにユーザーが入力する プロジェクトが正しく作成されたことを確認します UIのものといくつかの中間計画をスキップして、最初のユニットテストに行きます。 [TestMethod] public void CreateProject_BasicParameters_ProjectIsValid() { var testController = new Controller(); Project newProject = testController(A.Dummy<String>()); Assert.IsNotNull(newProject); } ここまでは順調ですね。赤、緑、リファクタリングなど。今では実際に保存する必要があります。ここでいくつかの手順を省略して、これで終わります。 [TestMethod] public void CreateProject_BasicParameters_ProjectMatchesExpected() { var fakeDataStore = A.Fake<IDataStore>(); var testController = new Controller(fakeDataStore); String expectedTitle = fixture.Create<String>("Title"); Project newProject = testController(expectedTitle); Assert.AreEqual(expectedTitle, newProject.Title); } …

20 c#  agile  unit-testing  tdd  refactoring 

TL; DR 優れた有用なテストを書くのは難しく、C ++でのコストは高くなります。経験豊富な開発者は、何をいつテストするかについての論理的根拠を共有できますか？ 長い話 私はチーム全体でテスト駆動開発を行っていましたが、実際にはうまくいきませんでした。多くのテストがありますが、実際のバグやリグレッションがあるケースをカバーすることはないようです-通常、ユニットが相互作用しているときに発生し、孤立した動作からではありません。 これは多くの場合、ユニットレベルでテストするのが非常に難しいため、TDDの実行を停止し（開発を実際にスピードアップするコンポーネントを除く）、代わりに統合テストの対象範囲を増やすためにより多くの時間を費やしました。小規模なユニットテストは実際のバグをキャッチすることはなく、基本的にメンテナンスオーバーヘッドにすぎませんでしたが、統合テストは本当に努力する価値がありました。 今、私は新しいプロジェクトを継承しましたが、それをテストする方法を知りたいと思っています。ネイティブのC ++ / OpenGLアプリケーションであるため、統合テストは実際にはオプションではありません。しかし、C ++でのユニットテストはJavaよりも少し難しく（明示的にものを作成する必要がありますvirtual）、プログラムはオブジェクト指向ではないため、いくつかのものをモック/スタブすることはできません。 テストを書くためにいくつかのテストを書くためだけに、すべてを引き裂いてオブジェクト指向化したいとは思いません。だから私はあなたに尋ねています：それは何のためにテストを書くべきですか？例えば： 頻繁に変更する予定の関数/クラス 手動でテストするのがより難しい関数/クラス？ すでにテストが簡単な関数/クラス？ 敬意を表するいくつかのC ++コードベースを調べて、テストがどのように行われるかを確認し始めました。今はChromiumのソースコードを調べていますが、コードからテストの理論的根拠を抽出するのは難しいと感じています。人気のあるC ++ユーザー（委員会、本の著者、Google、Facebook、Microsoftなど）がこれにどのようにアプローチしているかについて、良い例や投稿がある場合は、さらに役立つでしょう。 更新 これを書いて以来、私はこのサイトとウェブを探索しました。良いものを見つけました： 単体テストを行わないのはいつが適切ですか？ /programming/109432/what-not-to-test-when-it-comes-to-unit-testing http://junit.sourceforge.net/doc/faq/faq.htm#best 悲しいことに、これらはすべてJava / C＃中心です。Java / C＃で多くのテストを作成することは大きな問題ではないため、通常は利益がコストを上回ります。 しかし、上で書いたように、C ++ではより困難です。特に、コードベースがそれほどオブジェクト指向でない場合は、ユニットテストのカバレッジを良好にするために、物事をひどく混乱させる必要があります。例えば、私が継承したアプリケーションにGraphicsは、OpenGLの上にある薄層の名前空間があります。すべてのエンティティをテストするには、すべてのエンティティがその機能を直接使用するため、これをインターフェイスとクラスに変換し、すべてのエンティティに挿入する必要があります。それはほんの一例です。 したがって、この質問に答えるとき、テストを書くためにかなり大きな投資をしなければならないことに注意してください。

20 c++  unit-testing  tdd  integration-tests 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 自白します。形式化された自動化されたテストは、私のプログラミングの背景の一部ではありませんでした。現在、私は多くの開発者（大部分は何らかの種類のWeb開発者）を抱える非常に大きな会社で働いていますが、彼らのほとんどもテストしていないことは明らかです*。（* 正式に発言し続けるつもりはありません。推測してください。） テストを開始するために組織のサポートを受けるのを待つ場合、それは決して起こりません。経営陣のテストを押して「内部から物事を変えよう」とすると、変化が起こる前に枯渇してしまいます。今すぐテストを開始する必要があります。 しかし、TDDとその同類を使用すると、実動コードと一緒に多くのテストコードを作成することになります。バージョン管理システム（すべて集中管理）は、テストコードを保存するために編成されていません。ワークステーション上ですべての場所を見つける必要があります。 価値のない、またはツールを提供しない文化の中で、ソフトウェアテストの個人的な実践を始めることは可能ですか？公式のツールと組織にテスト、フレームワーク、および自動化の場所がない場合にテストできるようにするために、どのようなテクニックとツールを使用しますか？

20 testing  tdd 

予備メモ さまざまな種類のテストの違いについては説明しませんが、これらのサイトには既にいくつかの質問があります。 私はそこに何を取るだろうと、それは言う：単位は、「アプリケーションの最小単離ユニットテスト」の意味でのテストこの質問は、実際に由来します 分離の問題 プログラムの最小の分離可能な単位は何ですか。さて、私が見ているように、それは（非常に？）あなたがコーディングしている言語に依存します。 Micheal Feathersは縫い目の概念について語っています：[WEwLC、p31] シームは、その場所で編集せずにプログラムの動作を変更できる場所です。 そして、詳細に立ち入ることなく、私は、ユニットテストのコンテキストで、あなたの「テスト」があなたの「ユニット」とインターフェースできるプログラムの場所であると理解しています。 例 特にC ++の単体テストでは、テスト対象のコードから、特定の問題に対して厳密に要求される継ぎ目を追加する必要があります。 例： 非仮想実装で十分な仮想インターフェースを追加する 分割-generalizing（？）-テストを追加しやすくするための（さらに小さな）クラス 単一の実行可能プロジェクトを、一見「独立した」ライブラリに分割し、テストのためにそれらを独立してコンパイルしやすくするために「ちょうど」。 質問 同じことを願ういくつかのバージョンを試してみましょう。 ユニットテストでアプリケーションのコードを構造化する必要があるのは、ユニットテストに「のみ」有益であるか、実際にはアプリケーション構造に有益ですか。 必要とされるコードの一般化は、それがユニット・テスト可能な何のために有用にすることですが、ユニットテスト？ 単体テストを追加すると、不必要に一般化されますか？ シェイプユニットテストは、コードに「常に」強制することも、問題の領域から見た一般的なコードの良い形ですか。 コードを使用する2番目の場所が必要になるまで/必要になるまで一般化しないと言った経験則を覚えています。単体テストでは、コードを使用する2番目の場所、つまり単体テストが常にあります。それで、この理由は一般化するのに十分ですか？

20 c++  unit-testing  tdd  generalization 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 来週、ユニットテストとテスト駆動開発について私の部署に講演する予定です。その一環として、最近書いたコードから実際の例をいくつか紹介しますが、講演で書く非常に簡単な例をいくつか紹介したいと思います。 私はウェブ上で良い例を探してきましたが、開発分野に特に当てはまるものを見つけるのに苦労していました。私たちが作成するソフトウェアのほとんどは、小型のマイクロコントローラーで実行される埋め込み型の制御システムです。ユニットテストに簡単に適用できる多くのCコードがあります（ターゲット自体ではなくPCでユニットテストについて説明します）。「下」の層から直接離れている限り：直接話すものマイクロコントローラー周辺機器に。しかし、私が見つけたほとんどの例は文字列処理に基づいている傾向があります（たとえば、優れたDive Into Python Romanの数字の例）。文字列を使用することはほとんどないため、これは実際には適切ではありません（コードが通常使用する唯一のライブラリ関数について）ありmemcpy、memcmpそしてmemset、strcat または正規表現は正しくありません）。 では、質問に答えてください。ライブセッションで単体テストのデモンストレーションに使用できる機能の良い例を提供してくれる人はいますか？私の（変更される可能性がある）意見での適切な答えは、おそらく次のとおりです。 誰でも（たまにコードを書くだけでも）理解できるほど単純な関数。 無意味に見えない関数（つまり、パリティまたはCRCを計算することは、おそらく2つの数値を乗算してランダムな定数を追加する関数よりも優れています）。 人の部屋の前に書くのに十分短い関数（エラーを減らすためにVimの多くのクリップボードを利用するかもしれません...）; 文字列を処理するのではなく、数値、配列、ポインター、または構造体をパラメーターとして受け取り、類似のものを返す関数。 単純なエラー（例えば）>ではなく、簡単に入力できる関数は、>=ほとんどの場合は動作しますが、特定のエッジケースで破損する可能性があります。ユニットテストで簡単に識別および修正できます。 何かご意見は？ おそらく関連性はありませんが、テスト自体はおそらくGoogle Test Frameworkを使用してC ++で記述されます。すべてのヘッダーには既に#ifdef __cplusplus extern "C" {ラッパーがあります。これは、これまでに行ったテストでうまく機能しました。

20 unit-testing  c  tdd  embedded-systems 

組織のガイドラインをまとめるための単体テストのベストプラクティスを調査する際、テストフィクスチャ（テストクラス）を分離するか、1つのクラスのすべてのテストを1つのファイルに保持する方が良いか便利かという問題に直面しました。 ちなみに、純粋な意味での「ユニットテスト」とは、単一のクラス、テストごとに1つのアサーション、モックされたすべての依存関係などを対象とするホワイトボックステストのことです。 シナリオの例は、CheckInとCheckOutという2つのメソッドを持つクラス（Documentと呼ばれる）です。各メソッドは、動作を制御するさまざまなルールなどを実装します。テストごとに1つのアサーションルールに従って、メソッドごとに複数のテストがあります。およびのDocumentTestsような名前を持つ単一のクラスにすべてのテストを配置できます。CheckInShouldThrowExceptionWhenUserIsUnauthorizedCheckOutShouldThrowExceptionWhenUserIsUnauthorized または、2つの個別のテストクラスを持つことができます：CheckInShouldとCheckOutShould。この場合、テスト名は短縮されますが、特定の動作（メソッド）のすべてのテストが一緒になるように整理されます。 私はどちらのアプローチにも賛否両論があると確信しており、誰かが複数のファイルでルートを行っているのかどうか疑問に思っています。または、単一ファイルのアプローチを選択した場合、なぜそれが良いと感じるのですか？

20 testing  tdd  unit-testing 

私の会社のソフトウェア開発責任者は「辞任」（解雇）しましたが、現在、当社の開発慣行の改善を検討しています。これから作成されるすべてのソフトウェアに単体テストを実装したいと考えています。 開発者からのフィードバックはこれです： テストは価値があることを知っています ただし、仕様は常に変更されるため、時間の無駄になります。 そして、あなたの締め切りは非常に厳しいので、とにかくテストするのに十分な時間がありません CEOからのフィードバックは次のとおりです。 私たちの会社に自動化されたテストをしてもらいたいのですが、それを実現する方法がわかりません 大きな仕様書を書く時間がない 開発者はどのように仕様を入手しますか？口コミまたはPowerPointスライド。明らかに、それは大きな問題です。私の提案はこれです： また、開発者に一連のテストデータと単体テストを提供しましょう それが仕様です。それが望むものについて明確で定量的であるかどうかは、管理者次第です。 開発者は、必要と思われる他の機能は何でも配置でき、テストでカバーする必要はありません さて、あなたがこのような状況にあった会社にいたことがあれば、どのように問題を解決しましたか？このアプローチは合理的ですか？

19 unit-testing  tdd