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

私は本当に単体テストとTDDに夢中になりました-私はテストに感染しています。 ただし、ユニットテストは通常​​、パブリックメソッドに使用されます。ただし、プライベートメソッドでもいくつかの仮定（アサーション）をテストする必要がある場合があります。これは、それらの一部が "危険"であり、リファクタリングがそれ以上役に立たないためです。（フレームワークをテストすることでプライベートメソッドをテストできることはわかっています）。 したがって、プライベートメソッドの最初の行と最後の行の両方がアサーションであることが私の習慣になりました。 ただし、パブリックメソッド（およびプライベートメソッド）でアサーションを使用する傾向があることに注意してください。パブリックメソッドの前提条件は、ユニットテストフレームワークによって外部からテストされるため、これは「テストの重複」でしょうか。 誰かがあまりにも多くのアサーションをコードの匂いだと考えることはできますか？

19 testing  code-quality  tdd  code-smell  assertions 

一緒に仕事をしている優秀な開発者が、私たちが継承したコードに機能を実装するのに苦労したことを最近教えてくれました。彼は、問題はコードを追跡するのが難しいということだと言いました。そのことから、私は製品をより深く見て、コードパスを確認することがどれほど難しいかを理解しました。 非常に多くのインターフェースと抽象レイヤーを使用していたため、物事の始まりと終わりを理解しようとするのは非常に困難でした。私は過去のプロジェクト（きれいなコードの原則に気付く前に）を見ていた時間について考えさせられ、主にコードナビゲーションツールが常にインターフェイスに到達するため、プロジェクトを回避することは非常に困難であることがわかりました。具体的な実装や、プラグインタイプのアーキテクチャで何かが接続されている場所を見つけるには、さらに多くの労力が必要です。 この理由から、一部の開発者は依存性注入コンテナを厳密に拒否しています。ソフトウェアのパスを非常に混乱させるため、コードナビゲーションの難易度は指数関数的に増加します。 私の質問は次のとおりです。フレームワークまたはパターンがこのように多くのオーバーヘッドを導入する場合、それは価値がありますか？実装パターンが不十分な場合の症状ですか？ 開発者は、フラストレーションを乗り越えるために、抽象化がプロジェクトにもたらすものの全体像を調べる必要があると思います。しかし、通常、彼らにその全体像を見せることは困難です。IOCとDIのニーズをTDDで販売できなかったことを知っています。これらの開発者にとって、これらのツールを使用すると、コードの可読性が非常に低下します。

19 testing  code-quality  tdd  code-smell  dependency-injection 

私はユニットテストで把握しようとしています。 デフォルトの辺の数が6に等しい（ただし、4、5辺など）ことができるダイがあるとします。 import random class Die(): def __init__(self, sides=6): self._sides = sides def roll(self): return random.randint(1, self._sides) 以下は有効/有用な単体テストでしょうか？ 6面ダイスの1〜6の範囲でロールをテストします 6面ダイスの0のロールをテストします 6面ダイスの7のロールをテストします 3面ダイスの1〜3の範囲でロールをテストします。 3面ダイスの0のロールをテストします 3面ダイスの4のロールをテストします ランダムモジュールが長い間存在していたので、これらは時間の無駄だと思っていますが、ランダムモジュールが更新された場合（たとえば、Pythonバージョンを更新した場合）、少なくともカバーされます。 また、ダイロールの​​他のバリエーション（この場合は3など）をテストする必要もありますか、それとも別の初期化されたダイの状態をカバーするのが良いでしょうか？

18 python  unit-testing  tdd 

医療ソフトウェアのケースに基づいたTDDトレーニング中に、「ユーザーが[保存]ボタンを押すと、システムは患者を追加し、デバイスを追加し、デバイスデータレコードを追加する」というストーリーを実装します。 最終的な実装は次のようになります。 if (_importDialog.Show() == ImportDialogResult.SaveButtonIsPressed) { AddPatient(); AddDevice(); AddDeviceDataRecords(); } それを実装する方法は2つあります。 それぞれが1つのメソッド（AddPatient、AddDevice、AddDeviceDataRecords）を検証した3つのテストが呼び出されました 3つのメソッドすべてを検証する1つのテストが呼び出されました 最初のケースでは、if句の条件に何か問題が発生した場合、3つのテストすべてが失敗します。しかし、テストが失敗した場合の2番目のケースでは、何が正確に間違っているのかわかりません。どのような方法を好むでしょうか。

18 unit-testing  tdd 

「確かにわかるのに、なぜあなたのテストは良いと思うのですか？Jesterは私のテストが気密であると言うこともありますが、見つかった変更が突然発生することもあります。強くお勧めします。」-ケントベック しかし、stackoverflowには「Jester」というタグすらありません。では、Jesterの最新の代替品はありますか？CoberturaやCloverなどのツールのコードカバレッジから統計を見つけること以外に、記述された単体テストが堅実であることをどのように確認できますか？

18 java  unit-testing  code-quality  tdd 

ユニット/機能テストなしの大規模なエンタープライズレベルのアプリケーションがあるとします。非常に厳しい締め切りのために、開発中にテスト駆動型の開発プロセスはありませんでした（わからない場合、締め切りを約束するべきではありませんが、何が行われたかはわかりません！） すべての期限が過ぎ、物事が落ち着いたので、誰もが生産的なTDD / BDDベースのチームに私たちを変えることに同意しました。 問題は、すでにあるコードについてです：（1）すべてが完全に正常に動作していても、ほとんどの開発を停止し、最初から可能なテストケース全体を書き始めることはまだ大丈夫ですか？ ？または、（2）何か悪いことが起こるのを待ってから、修正中に新しい単体テストを作成するか、（3）以前のコードを忘れて、新しいコードのみの単体テストを作成し、次の主要なリファクタリングにすべてを延期する方がよいでしょう。 このようないくつかの良い関連記事があります。私たちには非常に限られた時間しかなく、他の多くのプロジェクト/作品が私たちを待っているので、これに投資する価値があるかどうかはまだわかりません。 注：この質問は、開発チームの完全に厄介な状況を説明/想像しています。これは私や同僚のことではありません。それは単なる想像上の状況です。これは絶対に起こらないか、開発マネージャーがそのような混乱に責任があると思うかもしれません！しかし、とにかく、行われたことが行われます。可能であれば、これは絶対に起こらないと思われるからといって、投票しないでください。

17 unit-testing  testing  tdd  bdd  acceptance-testing 

クライアントからの非常に特定の要件ごとに、検索結果の順序付けられていないリストのソートを支援するために、リストコンパレータに取り組んでいます。要件では、重要度の順に次のルールを使用してランク付けされた関連性アルゴリズムが必要です。 名前の完全一致 検索クエリのすべての単語の名前または結果の同義語 検索クエリの一部の単語の名前または結果の同義語（％降順） 説明内の検索クエリのすべての単語 説明内の検索クエリの一部の単語（％降順） 最終更新日が降順 このコンパレータの自然なデザインの選択は、2の累乗に基づいてスコア付けされたランキングであるように思われました。重要度の低いルールの合計は、重要度の高いルールの肯定的な一致を超えることはありません。これは、次のスコアによって達成されます。 32 16 8（降順％に基づく2次タイブレーカースコア） 4 2（降順％に基づく2次タイブレーカースコア） 1 TDDの精神で、私は最初にユニットテストから始めることにしました。一意のシナリオごとにテストケースを作成することは、ルール3および5のセカンダリタイブレーカーロジックの追加のテストケースを考慮せずに、少なくとも63の一意のテストケースになります。これは耐えがたいようです。 ただし、実際のテストは実際には少なくなります。実際のルール自体に基づいて、特定のルールにより、下位のルールが常に真になることが保証されます（たとえば、「すべての検索クエリワードが説明に表示される」場合、ルール「一部の検索クエリワードが説明に表示される」は常に真になります）。それでも、これらの各テストケースを書き出す努力のレベルは価値がありますか？これは、TDDで100％のテストカバレッジについて話すときに通常要求されるテストのレベルですか？そうでない場合、許容可能な代替テスト戦略は何でしょうか？

17 algorithms  unit-testing  tdd 

JDBCアクセスにSpringを使用するDAOメソッドがあります。これは、アイテムを販売する売り手の成功率を計算します。 コードは次のとおりです。 public BigDecimal getSellingSuccessRate(long seller_id) { String sql = "SELECT SUM(IF(sold_price IS NOT NULL, 1, 0))/SUM(1) FROM transaction WHERE seller_id = ?"; Object[] args = {seller_id}; return getJdbcTemplate().queryForObject(sql, args, BigDecimal.class); } このメソッドまたはDAOメソッドをJUnitでテストするにはどうすればよいですか？データアクセスロジックをテストするためのベストプラクティスは何ですか？いくつかのデータがロードされた埋め込み可能なデータベースに対してテストすることを考えていますが、RDBMSとスキーマの点で本番環境と同様の統合テストを行うべきではありませんか？

17 java  programming-practices  testing  tdd 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 テスト駆動開発を使用して開発されたオープンソースアプリケーションは、単体テストがどのように機能するかのモデルとして機能しますか？ C＃と.NETの例をご覧ください。（ライブラリだけでなく、アプリケーションについても言及していることに注意してください。） 私は、TDDを信じて実践したい中間層のプログラマーです。私が日々の仕事で取り組んでいるアプリはかなり複雑です（約100万行のコード）。さらに単体テストを導入したいと思います。いくつかの単体テストが用意されていますが、TDDでの努力と、既にテスト中のコードの作業は励みになりませんでした。 私の認められた限られた経験では、TDDはデカップリングの名前の多くの複雑さを奨励するようです。テストするのが難しく、偶然にもクリティカルになる傾向があるアプリの一部は、周辺にプッシュされ、統合テストの領域に書き込まれます。（私はここでの通常の容疑者、ファイルシステムへのアクセス、データベースからのオブジェクトのハイドレーション、非同期ウェブコールなどを考えています） テスト中のコードには、オブジェクト間の多くのコラボレーションが含まれる傾向があり、おそらくいくつかの単純なフローロジックはすべてメモリ内で発生し、すべてを完全に分離する必要がなければ、おそらくよりシンプルで理解しやすい方法で記述できます検査用の。 私は依存関係などをモックするテクニックを理解していますが、私の経験では、モックを多用すると非常に脆弱なテストになります。一連のテストが赤くなるのを見て最初の本能が「すごい、今はすべてのモックを修正しなければならない」という場合、テストはセーフティネットではなくドラッグになっています。 私はこの精神的な障壁を乗り越えようとしていますが、その一環として、マイケルフェザーズの著書「Working Effectively with Legacy Code」を読んでいます。不足しているものの一部を見せてくれることを願っています。 また、コードカバレッジが良好な自明ではない.NETアプリケーション（コンテンツ管理システム、CRUDアプリなど）を調べたいと思います。ボブおじさんが語るFitNesseテストフレームワークは、おそらく検討するものですが、私が最もよく知っている言語で書かれたものを見るといいでしょう。 提案や知恵の言葉は大歓迎です。

17 unit-testing  tdd 

プログラミングは初めてではなく、AVRで低レベルのCおよびASMを使用したこともありますが、大規模な組み込みCプロジェクトを回避することはできません。 RubyのTDD / BDDの哲学に退化されているため、このようなコードを作成してテストする方法を理解することはできません。私はそれが悪いコードだと言っているのではなく、これがどのように機能するのか理解していません。 低レベルのプログラミングにもっと入りたいと思っていましたが、これにどのようにアプローチするのか全く分かりません。それは私が慣れ親しんだまったく異なる考え方のように見えるからです。ポインターの計算やメモリの割り当ての仕組みを理解するのに問題はありませんが、Rubyと比較して複雑なC / C ++コードがどのように見えるかを見ると、信じられないほど難しいようです。 すでにArduinoのボードを注文しているので、低レベルCをさらに理解して、物事を適切に行う方法を本当に理解したいと思いますが、高レベル言語のルールは適用されないようです。 組み込みデバイスでTDDを実行したり、ドライバーやカスタムブートローダーなどを開発したりすることも可能ですか？

17 c  tdd  embedded-systems 

私はTDDの理論をほとんど理解していますが、どのように始めればよいのかわかりません。個人プロジェクトのユニットテストを書いて実現するために座っています。。。何をテストしているのかわかりません。どのオブジェクト、どの機能など 例えば、私たちの家族が雑用の割り当てを管理するのに役立つアプリを書きたいとしましょう。ここに私の頭の中にいくつかの質問があります：このアイデアから最初のテストに行くにはどうすればいいですか？始める前にどれくらい決める必要がありますか。また、テストの作成を開始した後、どれだけ把握する必要がありますか データをテキストファイルとデータベースのどちらに保存するかなどの決定はいつ行いますか？開始する前にユーザー受け入れテストを行う必要がありますか？UIを設計する必要がありますか？スペックが必要ですか？（これらの例の質問の少なくともいくつかがおそらく「灰色の領域」にあることを理解しています）。 最初の単体テストにたどり着くというタイトルの質問に加えて、サンプルプロジェクトのようなプロジェクトの最初の単体テストがどのように見えるかも例を示してください。

17 design  tdd 

これらは、TDDに関するRobert C. Martinの規則です。 失敗した単体テストに合格しない限り、実稼働コードを作成することはできません。 失敗するのに十分な数以上の単体テストを作成することはできません。コンパイルの失敗は失敗です。 1つの単体テストに合格するのに十分な量を超える量産コードを記述することはできません。 価値があると思われるが、本番コードを変更せずに合格するテストを作成する場合： それは何か間違ったことをしたということですか？ 役立つ場合は、将来そのようなテストを書くことを避けるべきですか？ そのテストをそこに残すか、削除する必要がありますか？ 注： 私はここでこの質問をしようとしていました：ユニットテストに合格することから始められますか？ しかし、私は今まで十分に質問を明確にすることができませんでした。

17 testing  unit-testing  tdd 

私はTDDを宗教的に守ります。私のプロジェクトは通常、テストカバレッジが85％以上であり、意味のあるテストケースがあります。 私はHBaseで多くの作業を行っていますが、メインのクライアントインターフェイスであるHTableはモックの苦痛です。ライブエンドポイントを使用するテストを記述するよりも、ユニットテストを記述するのに3〜4倍時間がかかります。 哲学的に、モックを使用するテストは、ライブエンドポイントを使用するテストよりも優先されるべきであることを知っています。しかし、HTableのモックは深刻な痛みであり、実際のHBaseインスタンスに対するテストよりも多くの利点があるとは確信していません。 私のチームの全員がワークステーションでシングルノードHBaseインスタンスを実行し、JenkinsボックスでシングルノードHBaseインスタンスを実行しているため、可用性の問題はありません。ライブエンドポイントテストは、モックを使用するテストよりも明らかに実行に時間がかかりますが、実際には気にしません。 現在、すべてのクラスに対してライブエンドポイントテストと模擬ベースのテストを作成しています。モックを捨てたいのですが、結果として品質が低下するのは望ましくありません。 皆さんはどう思いますか？

16 unit-testing  tdd  integration-tests  mocking 

ここで何が尋ねられているかを伝えるのは難しいです。この質問は曖昧、曖昧、不完全、過度に広範、または修辞的であり、現在の形式では合理的に答えることができません。この質問を明確にして、再開できるようにするには、ヘルプセンターに アクセスしてください。 8年前に閉鎖されました。 どのようなソフトウェアテストを知っていますか？テスト駆動開発、単体テストなどについて聞いたことがありますが、それらの重要性と違いを理解できません。たとえば、なぜ回帰テストや受け入れテストを使用するのでしょうか。彼らが提供する利点は何ですか？

16 unit-testing  testing  tdd  integration-tests  acceptance-testing 

興味深いことに、メディアがどこにあるかを見るために、この質問をそこに投げ出したいと思います。 過去12か月で、TDDとソフトウェア開発におけるアジャイルの価値の多くを取り上げました。私はソフトウェアの開発がどれほど良くなったかに圧倒され、それらを原則から外すことはありませんでした。まで...私は年間の持ち帰り給与を倍増する契約の役割を提供されました。 私が参加した会社は特定の方法論を踏んでおらず、チームはコードの匂いやソリッドなどのことを聞いていませんでしたし、チームでさえもしていないなら、TDDに時間を費やすことはありませんでした実際にユニットテストを見ました。売り切れですか？いいえ、完全ではありません...コードは常に「ボブおじさんの教えに従って」「きれいに」書かれ、SOLIDの原則は必要に応じて私が書くコードに常に適用されます。しかし、テストフレームワークを作成したとしても、テストフレームワークを正しく使用/保守することはありませんでした。 それを例にとると、開発者は個人的にお金/その他の利益のために職人技の原則を落とすべきではないという点を教えてください。これは、自分のニーズ、ビジネスニーズ、職人技などのためにどれだけ関心があるかについて、非常に個人的な意見になり得ることを理解しています。しかし、たとえば、テストチームは、プログラミングの単体テストを理解するのではなく、私がやったように自分自身を許すことができるでしょうか？あなたが落とすものがあることを考えると、通常はあなたが落とすものを補うビジネスに等しい費用があるはずです-できれば、もちろんあなたがあなた自身のポケットを並べてコミュニティ/社会的コラボレーションではなく）。 お金を2倍にして、RADに戻りますか？または、歩いて、アジャイルをしている人を探して、決して振り返らないでください...

16 agile  testing  unit-testing  tdd  sdlc