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

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

6
単体テストなしのアジャイル
作業しているコードベースのユニットテストカバレッジが0％である場合、「アジャイル開発」または「アジャイル手法」を適用していると主張することは理にかなっていますか？（そして、チームとして、あなたはそれについて何もしていません）。 それを明確にするために：私にとって、それは意味がありません。私の個人的な経験では、ユニットテストが実際に「アジャイル」（つまり、変更への対応、設計の改善、知識の共有など）を可能にする唯一のツールであり、TDDが唯一の手段であることがわかりました。 。 他の方法もあるかもしれませんが、どのように機能するかはまだわかりません。
6
「コードのテスト行」に対する「コードの機能行」の通常の比率は何ですか？
私はTDDアプローチにかなり慣れており、最初の実験では、1行の機能コードを記述することは、2〜3行のテストコードを記述することを意味します。したがって、1000 LOCを記述する場合、テストを含むコードベース全体は〜3500 LOCのようなものになります。 これは正常と見なされますか？あなたが書くコードの割合は何ですか？
5
TDDの使用を開始します。初心者向けのヒントはありますか？[閉まっている]
私はどのプロジェクトでも自動テストメカニズムを使用したことはなく、多くのことを失っていると感じています。私は自分自身を改善したいので、私はこのように無視してきたいくつかの問題に取り組み始め、SVNに固執する代わりにGitを試す必要があります。 TDDを学ぶ良い方法は何ですか？おそらくEclipseを使用してJavaでプログラムするでしょう。JUnitのことは聞いたことがありますが、他に検討すべき点があるかどうかはわかりません。
6
ユニットテストにどれくらいの時間を費やしていますか？
私が働いていた会社では、経営陣はユニットテストのコードカバレッジが99％以上でなければならないと主張しました。これは、コードよりも多くのテストを書くことになりました。実装に1日かかった単一のクラスのテストを書くのに、文字通り3日かかりました。 しかし、その結果、TDD、テストツール、プラクティスなどについて多くのことを学びました。 私がその後働いた会社では、単体テストは未知のものでした。それは誰かが前に聞いたことがあるかもしれないものでした。単体テストの概念を紹介するのに苦労しましたが、効果はありませんでした。 さて、自営業として、私は疑問に思う-あるどのくらいの時間は本当にユニットテストに費やす必要が？ほとんどがiPhone / Android開発者であるため、コードのどの部分をテストでカバーする必要がありますか？
6
TDDとバージョン管理
現在、TDDについて学び、個人プロジェクトでTDDを実践しようとしています。また、これらのプロジェクトの多くでバージョン管理を広範囲に使用しました。私は、特にコミットを小さく保つという格言に関しては、典型的なワークフローにおけるこれら2つのツールの相互作用に興味があります。ここに思い浮かぶいくつかの例があります： 新しいプロジェクトを開始し、まだ存在しないクラスを作成する簡単なテストを作成します。テストがコンパイルされない場合でも、クラスを作成する前にテストをコミットする必要がありますか？または、コミットする前にテストをコンパイルするために必要な最小限のコードをスタブアウトする必要がありますか？ バグを見つけ、テストを作成して再作成します。失敗したテストをコミットするか、バグ修正を実装してからコミットする必要がありますか？ これらは、すぐに思い浮かぶ2つの例です。回答に追加の例を提供してください。 編集： 両方の例で、テストを書いた直後にテストをパスするコードを書くと仮定しました。別の状況も発生する可能性があります。私は、コミットせずに数時間TDDを使用してプロジェクトに取り組んでいます。最終的にコミットするとき、作業を小さなチャンクに分割します。（Gitは、1つのファイルの一部の変更のみをコミットしたい場合でも、これを比較的簡単にします。） これは、私の質問は、いつコミットするかということと同じくらいコミットすることに関することを意味します。
11
自動テスト：そのビジネス価値の説明
この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 私はこれがあるとは思いません起動するには、繰り返しの他の質問にユニットテスト。私が助けを求めているのは、プログラマー、アナリスト、マネージャー、テスターのチームにその価値を明確にすることです。自動テストでは、ユニットテスト（JUnitなど）、BDD（JBehave、Fitness）、UI（Selenium、Watir）を区別する必要はないと思います。同意しない答えを書いてください:)） 以下は私が特定したリストです。拡張または改善に役立つ答えを探しています： 時間/コストの節約：自動化されたテストの作成は、テストケースの作成よりも時間がかかる場合があります。ただし、テストが複数回実行されることを考慮すると、自動テストを実行するためのわずかな作業（コスト/時間）が数桁少なくなります。自動テストの実行が安価であることは、時間の経過に伴うシステムの変更を促進します。 ドキュメンテーション：システムがどのように機能するかを知るためのより正確な方法は、テストよりもありません。他のドキュメントは、通常、作成された時点では古くなっていますが、テスト（少なくとも合格したもの）により、実際の動作が明らかになります。これは、エンドユーザーおよびAPIドキュメントの両方に当てはまります。 コード品質：テスト作成により、次のことが強制されます。 テストはクライアントであるため、クライアントを考慮する コードをテスト可能にすることは、多くの場合、他の大規模システムを必要としないコードを作成する方法を見つけ出すことを意味します。
3
単体テストでの循環的な依存関係との闘い
私はTDDを使って、Bit Vectorのような単純なものを開発することで、TDDを実践しようとしています。私はたまたまSwiftを使用していますが、これは言語に依存しない質問です。 My BitVectorは、struct単一のを格納し、そのUInt64上にコレクションのように扱うことができるAPIを提供します。詳細はさほど重要ではありませんが、非常に簡単です。上位57ビットはストレージビットであり、下位6ビットは「カウント」ビットであり、格納された値を実際に格納するストレージビットの数を示します。 これまでのところ、非常にシンプルな機能がいくつかあります。 空のビットベクトルを構築する初期化子 countタイプのプロパティInt isEmptyタイプのプロパティBool 等号演算子（==）。注意：これは、JavaのObject.equals()ような参照等価演算子ではなく、==Javaのような値等価演算子です。 私は周期的な依存関係の束に直面しています： イニシャライザをテストする単体テストでは、新しく構築されたを確認する必要がありBitVectorます。次の3つの方法のいずれかで実行できます。 チェック bv.count == 0 チェック bv.isEmpty == true それを確認します bv == knownEmptyBitVector 方法1は依存count、方法2は依存isEmpty（それ自体が依存しているcountため、使用する意味はありません）、方法3は依存してい==ます。いずれにしても、初期化子を単独でテストすることはできません。 のテストはcount何かを操作する必要があり、必然的に私のイニシャライザーをテストします の実装は、にisEmpty依存していますcount の実装はに==依存していcountます。 BitVector（aとしてUInt64）既存のビットパターンからを構築するプライベートAPIを導入することにより、この問題を部分的に解決することができました。これにより、他のイニシャライザーをテストせずに値を初期化できたので、「ブートストラップ」することができました。 ユニットテストが本当にユニットテストであるためには、たくさんのハックをしていることに気付きます。 この種の問題をどのように正確に回避しますか？
7
TDD /テストのオーバーヘッド/メンテナンスの負担が大きすぎますか？
そのため、テストの価値を本当に理解していない人から何度も聞いています。物事を始めるために、私はアジャイルとテストのフォロワーです... 私は最近、製品の書き換えでTDDを実行することについて議論しました。現在のチームはどのレベルでも単体テストを練習しておらず、おそらく依存性注入手法やテストパターン/デザインなどについて聞いたことがないでしょうコードをきれいにするために）。 現在、私はこの製品の書き換えについて完全に責任を負っており、TDDのように試してみると、単にメンテナンスが悪夢になり、チームがメンテナンスすることが不可能になると言われています。さらに、それはフロントエンドアプリケーション（Webベースではない）であるため、テストの追加は無意味です。ビジネスドライブが変化すると（当然、改善を意味します）、テストは時代遅れになります。将来のプロジェクトはそれらを維持せず、彼らが修正するなどの負担になるでしょう。 現在、テスト経験のないチームのTDDは良く聞こえないことは理解できますが、この場合の私の主張は、周囲に練習を教えることができるということですが、さらに、TDDがより良い結果をもたらすことを知っていますソフトウェア。TDDを使用してソフトウェアを作成し、メンテナンスチームに引き渡す際にすべてのテストを破棄する場合でも、TDDを最初から使用しないよりも確実に良い方法でしょうか。 TDDを聞いたことがないチームのほとんどのプロジェクトでTDDを行うことについて言及したので、私は撃downされました。「インターフェイス」と奇妙な外観のDIコンストラクターの考えは、それらを怖がらせます... 通常、TDDを販売しようとするという非常に短い会話や、人々への私のアプローチについて、誰か助けてください。会社/チームにひざまずく前に、私は通常非常に短い議論の窓を持っています。
24 testing  agile  tdd  bdd 
4
各ユニットテストは、他のテストとは独立して実行できる必要がありますか？
クラスの2つのメソッドのテストがあるとします。最初の方法では、別の層からデータを収集し、ランタイムに依存しない何らかの種類のストレージ（SQLテーブルなど）に格納するため、このテストで処理されるすべてのデータはテストにハードコーディングされます。2番目のメソッドは、最初のメソッドがデータを残した場所からデータを取得し、何らかの方法で変換（計算、特定の部分を他の場所に移動するなど）を担当します。 この2番目の方法では、最初の方法と同様に入力をハードコーディングするか、2つのテストを連続して実行し、最初のテストで実際に保存されたデータを取得して、1番目のテストが中断した場所から再開できると想定できます。 2番目のオプションを選択した場合、2つの方法がうまく機能するというのは本当に良い考えですが、1番目のテストが失敗した場合、それ以降のすべてのテストは失敗し、バグをより迅速に特定するのに役立つテストの利点がなくなります。 最初のオプションを選択した場合、各メソッドは独立して分離され、テストされますが、それらが実際に適切に連携できることを本当に知ることはありません。 ここでより良いオプションはどれですか？ハードコーディングを使用して分離されたメソッドごとに単一のテストを実行し、次に両方のメソッドを1つに含むより大きなテストを実行するなど、何らかの方法がありますか？
6
チーム全体がTDDに慣れたら、TDDの実際のオーバーヘッドはどうなりますか？
TDDの実行に費やす時間の割合。 このコストと報酬の割合は、プロジェクトのライフサイクル中に変化すると想定しています。 私は想像する最初の段階は、添付のより多くのコストが、少しの報酬を持っています。さらに（リファクタリング中）テストの利点を得ることができます。 あなたの時間の30-50％がユニットテストを書いていると聞いています。ただし、これらのテストを記述することで節約される時間は考慮されていません。 これに関するみんなの経験はどうですか？ ウェス 編集時間の節約だけでなく、時間の節約もできますか？バグ修正とリファクタリングで？
24 productivity  tdd 
6
TDDでは、最初にTestまたはInterfaceを記述する必要がありますか？
私はテストが開発を促進する必要があることを知っている限り、c＃を使用してTDDを学んでいます。つまり、最初にテストに合格するために最低限のコードを書いてからリファクタリングを行ってから失敗するテストを書きます。 しかし、「実装ではなく、インターフェイスするプログラム」とも言われているため、最初にインターフェイスを記述します。ここから混乱が始まります。最初にInterfaceを書いている場合、2つのことに違反しています。 インターフェイス用に記述されたコードはtestによって駆動されません。 単純なクラスでそれを書くことができるのは、明らかに最低限のものではありません。 インターフェースのテストを書くことから始めなければなりませんか？実装なしで何をテストするのですか？ この質問がそれについて愚かに残念に思えるが、私は全く混乱しています。文字通りに物事を取っているかもしれません。
23 c#  unit-testing  tdd 
5
エンドツーエンドテストと単体テストの比較、テストを分離する必要がありますか？
私たちの会社では通常、Webサイト/ Webアプリのエンドツーエンドのテストを必ず作成します。つまり、URLにアクセスし、フォームに入力し、フォームを別のURLに送信して、ページの結果を確認します。これは、フォームの検証、HTMLテンプレートに正しいコンテキスト変数があることなどをテストするために行います。 また、基になるロジックを間接的にテストするためにも使用します。 同僚から、この理由は、エンドツーエンドのテストに合格する限り、任意の時点で基になる実装をリッピングおよび変更できるためだと言われました。 この種のデカップリングが理にかなっているのか、それとも小さなコード単位のテストを書くのを避けるための方法なのだろうか？
16
テスト駆動開発は誰が行うのですか？
ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 私は過去4年半にわたってエンタープライズの分野で働いてきましたが、一般的に言って、エンタープライズはテストファーストスタイルの開発を促進する環境ではないことに気付きました。プロジェクトは通常、固定コスト、固定タイムライン、およびウォーターフォールスタイルです。ユニットテストが行​​われたとしても、通常はQAフェーズでの開発後に別のチームによって行われます。 企業で働く前に、私は多くの中小企業に相談しましたが、テストファーストスタイルの開発プロジェクトにお金を払うつもりはありませんでした。彼らは通常、開発をすぐに開始するか、短い設計期間の後、つまりアジャイルに似たものを望んでいましたが、一部のクライアントはすべてがウォーターフォールのようにマッピングされることを望みました。 テスト駆動開発は、どのタイプのショップ、企業、クライアントで最も効果的ですか？どのタイプのプロジェクトがTDDを助長する傾向がありますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.