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

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

3
低レベルのコンポーネントでTDDを実行することは良い考えですか?
低レベルのドライバーまたはOSコンポーネント/カーネルの作成を検討しています。 osdev.orgの人々は、重要なビットが有意義にこの方法をテスト可能されていないことを考えているようだが、私は人々が異なったと思ったいくつかの議論を読んだことがあります。私は見回しましたが、低レベルコンポーネントのTDDの実際の例を見つけることができませんでした。 これは実際に人々が行うことですか、それとも実際にはそれを行う良い方法がないために理論的に人々が話していることですか?

2
リポジトリパターンを使用したTDD
私の新しいプロジェクトでは、TDDを試すことにしました。そして、最初に問題が発生しました。アプリケーションで最初にしたいことは、データソースからデータを読み取る機能を提供することです。この目的のために、私はリポジトリパターンを使用したいと思います。そしていま: テストがリポジトリー・インターフェースの実際の実装を対象としている場合、私はデータベースにアクセスできるクラスをテストしますが、それは避けなければならないことを知っています。 テストがレポジトリパターンの実際の実装ではない場合、私はうまくテストします...ただ模擬します。これらの単体テストでテストされる製品コードはありません。 私はこれを2日から考えていますが、それでも適切な解決策を見つけることはできません。私は何をすべきですか?

5
非常に大きなアプリケーションをテストする方法
私は非常に大きいPHPアプリを持っています。通常、2〜3人の開発者がフルタイムで取り組んでおり、変更を加えてバグ(咳機能)を作成するところまで来ています。ソフトウェアは言うまでもなく複雑ではありません。多くのことが起こっているだけです(35〜コントローラー、同じモデルなど)。 注意していても、このビューを変更すると(要素のIDを微調整)、特別な条件(片足でログアウトしている)で発生するajaxクエリが壊れるのは簡単です。 ユニットテストは最初に思い浮かぶものですが、別のアプリで試してみたので、それらを忘れたり、テストを記述してからテストを実行したりすることに多くの時間を費やすことは簡単です。ライブ配信する前にコードがチェックされるステージング環境があります。 多分パートタイムのQ / Aの人が必要ですか? 誰もが何か提案/考えを持っています。

5
TDDが設計に関するものである場合、なぜそれが必要なのですか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 TDDの第一人者は、TDDがテストではなく、デザインに関するものであることをますます伝えています。TDDなしで本当に素晴らしいデザインを作成する開発者を知っています。彼らはTDDを実践すべきでしょうか?
10 tdd 

1
機能スタイルは依存関係のモックにどのように役立ちますか?
最近のJava Magazine号のKent Beckへのインタビューから: Binstock:マイクロサービスについて説明しましょう。一部のサービスが機能するためには、他のサービスの束全体の存在が必要になるという意味で、マイクロサービスのテストファーストは複雑になるように思えます。同意しますか? ベック:1つの大きなクラスまたはたくさんの小さなクラスを持つことについては、同じトレードオフのセットのようです。 Binstock:そうです、私が推測する場合を除いて、特定のサービスをテストできるシステムをセットアップできるようにするためには、ここでは非常に多くのモックを使用する必要があります。 ベック:そう思わない。命令型のスタイルの場合は、モックをたくさん使用する必要があります。外部依存関係がコールチェーンの上位に集められている関数型のスタイルでは、それは必要ないと思います。単体テストから多くの報道を得ることができると思います。 彼はどういう意味ですか?機能的なスタイルで、外部の依存関係をあざけることからどのように解放できますか

2
UMLダイアグラムを使用してコードの編成方法を計画することが不適切なのはなぜですか?
そのため、はい、図が不適切な場合があります。彼らはいつ不適切ですか?それらを検証するためのコードなしでそれらを作成し、それらに従うことを意図している場合。アイデアを探求するために図を描くことには何の問題もありません。 アジャイルソフトウェア開発:原則、パターン、および実践-Robert C. Martin これは正確にはどういう意味ですか?UMLは、「ダイブイン」する前にコードを構造化する方法を計画するのに役立つように設計されていませんか?あなたが思いついた図に従わない場合、それを使用する意味は何ですか? コンテキスト:この章では、ボブおじさんがボウリングゲームのスコアキーパーのUML図を作成します。次に、UML図を調べずに、テスト駆動の方法でプログラムを開発します。結果のプログラムはUMLダイアグラムとは異なり、ボブおじさんは上記の結論に達します。

3
クロスランゲージテスト駆動開発
短い質問:複数の言語にまたがるプロジェクトでテスト駆動開発をどのようにフォローしますか? 具体的には、JavaScriptとPHPを使用するWebアプリケーションを作成していて、TDDの原則に従いたいのですが、それらを統合する方法がわかりません。JSセクションとPHPセクションで別々のテストスイートを実行し、JSスイートのモックを使用してサーバーの応答をエミュレートしますか?1回の実行で両方のコンポーネントを単体テストする手法はありますか? これは、テスト駆動開発を使用した私の最初の経験なので、困難を少なくする方法について共有できるアドバイスがあればすばらしいでしょう。私がそれを選んだ理由は、プロトタイプが完成するとすぐに要件が変更され、設計を変更せざるを得なくなったためです。最初からやり直すのであれば、最初から組み込みの回帰テストを使ってより拡張可能なコードを書きたいと思っていました。 PHPテストはSimpleTestで、JavaScriptテストはJsTestDriverで作成しています。私はオブジェクト指向のパラダイムに慣れているので、PHPにはいくつかのクラスがあり、JavaScriptではプロトタイプ継承を使用して同様のことをしています。また、PythonでのTDDに関するこの本とJavaScriptでのTDD に関するこの本も読み始めましたが、これらすべては、Seleniumや別のWebドライバーなどを使用する以外のアプリケーションの完全なテストについては説明していません。フロントエンドの受け入れテストを実行するためにTDDはフルスタックの開発者のために切り取られていないだけですか?

2
DDDを実行するときにエンティティと値オブジェクトをモックする必要がありますか?
読んだ後、いくつかの 記事についてNewableを対注射のオブジェクトとどのようにこれらの概念は、DDDのサービス、エンティティと値オブジェクトに関連し、私は特に私のユニットテストで私のコードでnewablesの使用に関するいくつかの疑問が残りました。 Newableの主な候補は、EntitiesオブジェクトとValueオブジェクトでした。つまり、これらの依存関係を他のオブジェクトに注入する代わりにnew、これらのオブジェクトのインスタンスだけを作成して、コードで直接使用する必要があります。 ただし、適切なDDDプラクティスでは、エンティティと値オブジェクトに適切であると見なされた場合に責任を割り当てることを推奨しています。そのため、エンティティと値オブジェクトには、深刻なビジネスロジックが含まれなくなります。 ここで、サービスがエンティティまたは値オブジェクトで動作する場合、エンティティまたは値オブジェクトをモックしてサービスにモックを渡す必要があります(モックには、interface推奨されているように見える値オブジェクトまたはエンティティのが必要です)? またはnew、エンティティ/値オブジェクトだけを具体的な実装をサービスに渡して、1つのユニットのみをテストするというユニットテストの原則に違反する必要がありますか?

4
TDDを簡単に実行できるようにゼロから設計された新しい言語はどのように見えますか
いくつかの最も一般的な言語(Java、C#、Javaなど)では、コードを完全にTDDしたいときに、その言語と対立しているように見えることがあります。 たとえば、JavaとC#では、クラスの依存関係をモックする必要があり、ほとんどのモックフレームワークでは、クラスではなくインターフェイスをモックすることをお勧めします。これは、多くの場合、単一の実装で多くのインターフェースがあることを意味します(この影響は、TDDにより多数の小さいクラスを作成するよう強制されるため、さらに顕著になります)。具象クラスを適切にモックできるようにするソリューションは、コンパイラーを変更したり、クラスローダーをオーバーライドしたりするなど、かなり厄介です。 それで、TDDに最適になるようにゼロから設計された言語はどのようになりますか?(インターフェイスをコンストラクタに渡すのではなく)依存関係を記述する何らかの言語レベルの方法で、明示的に行うことなくクラスのインターフェイスを分離できるのでしょうか?

1
TDDを使用して簡単な機能をコーディングするにはどうすればよいですか?
基本的にTDDの要点があります。私はそれが便利で、MSTESTフレームワークの適切なコマンドを持っていることを売りました。しかし、これまでのところ、これを主要な開発方法として使用するように卒業することはできませんでした。ほとんどの場合、コンソールアプリをテストドライバーとして書くための代理として使用します(私の従来のアプローチ)。 私にとって最も便利なのは、回帰テストの役割を吸収する方法です。 さまざまなテスト可能な動作を明確に分離するものはまだ何も構築していません。これは、私が知っている画像のもう1つの大きな部分です。 したがって、この質問は、次の開発タスクのために最初に何を書くかについてのポインタを尋ねることです。プロデューサ/コンシューマの方法でタスクの実行をカプセル化するコードを作成したいと思います。 このコードを書いた後、私は立ち止まり、この質問を書くことにしました(今回、実際にTDDを実際に使用できるかどうか疑問に思いました) コード: interface ITask { Guid TaskId { get; } bool IsComplete { get; } bool IsFailed { get; } bool IsRunning { get; } } interface ITaskContainer { Guid AddTask(ICommand action); } interface ICommand { string CommandName { get; } Dictionary<string, object> Parameters { get; …
9 c#  tdd 

4
単体テストの「単体」で理解されること
私が理論上「ユニット」の下で理解しているように、人々は方法(OOP)を意味します。しかし、実際には、いくつかのメソッドを分離して検証するテストは、非常に壊れやすい動作テストです(結果ではなく、いくつかの依存関係メソッドが呼び出されたことを検証します)。そのため、密接に関連するクラスの小さなセットをユニットごとに理解する多くの人々を目にします。この場合、外部の依存関係のみがモック/スタブされ、ユニット内部の依存関係には実際の実装が使用されます。この場合、より多くの状態があり、(仕様によると)意味があり、それほど脆弱なテストではありません。したがって、問題はこれらのアプローチについてどのように感じていますか、2番目のアプローチの単体テストを呼び出すことは有効ですか、それとも何らかの低レベルの統合テストなのでしょうか? これらのテスト方法のいずれかによるTDDの適用に関する特定の考慮事項が表示された場合は、私はあなたの考えに感謝します。

3
BDD:はじめに
私はBDDから始めて、これが私の話です。 Feature: Months and days to days In order to see months and days as days As a date conversion fan I need a webpage where users can enter days and months and convert them to days. 疑問があります... 何かをコーディングする前にシナリオを書くべきでしょうか、それとも最初にシナリオを書いてからコードを書いたり、シナリオをもう一度書いてからコードを書いたりするべきでしょうか... 以前にシナリオを作成する必要がある場合、私のステップを承認しても製品コードはまだ完了しませんか? いつコードをリファクタリングする必要がありますか?機能が完了した後、または各シナリオの実装後?

4
単体テストの新しい名前[終了]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 私はユニットテストが好きではありませんでした。それは私がしなければならない仕事の量を増やすといつも思っていました。 結局のところ、これは実際に記述するコードの行数に関してのみ当てはまり、さらに、これは、テストおよびテスト駆動開発で1時間で記述できる有用なコードの行数の増加によって完全に相殺されます。 ユニットテストが便利なコードを記述できるようになった今、私はユニットテストが大好きです。(木のノック) 厳格なタイムラインの下にある場合、または他の人がそれを行わないためにそうしないために、人々がユニットテストを行うか、テスト駆動開発でプロジェクトを開始することに消極的であることがわかりました。ちょっとみたい、文化的な拒否すらしよう。 ユニットテストの最も強力な点の1つは、リファクタリングを実行できるという自信です。また、コードを他の誰かにリファクタリング/改善するために与えることができるという新しい発見の希望も得られます。ユニットテストが引き続き機能する場合は、恐らくほとんど変更せずに、変更された新しいバージョンのライブラリを使用できます。 新しい名前が必要だと思うのは、ユニットテストのこの最後の側面です。単体テストは、このコードが現在、そして将来的に何をすべきかについての契約のようなものです。 テストという言葉を聞くと、ケージ内のマウスを思い浮かべます。化合物の有効性を確認するために複数の実験が行われました。これは単体テストとは異なり、さまざまなコードを試して最も効果的なアプローチを確認するのではなく、期待する出力と入力を定義します。マウスの例では、ユニットテストは、マウスで行われた実験とは対照的に、宇宙がどのように機能するかの定義に似ています。 私はひび割れているのですか、それとも他の誰かがテストを拒否するのを見て、それを彼らがテストしたくないのと同じ理由であると考えていますか? テストしない理由は何ですか? ユニットテストではないので、彼らの動機は何だと思いますか? そして、いくつかの異論を乗り越えるかもしれないユニットテストの新しい名前として、jContractはどうですか?(私が知っている少しJava中心:)、またはユニット契約?

2
単体テストでプロジェクトを「使用」するか、それとも同じ名前空間を持っていますか?
バックグラウンド C#.NETでプロジェクトに取り組んでいますが、Visual Studioのソリューションに新しい単体テストプロジェクトを追加しました。私がこれをいつもやっている方法は: 新しい単体テストプロジェクトを作成します。 そのプロジェクトに、テスト中のプロジェクトへの参照を含めます。 プロジェクトを含める(using)だけです。 あなたができる他の方法は... 新しい単体テストプロジェクトを作成します。 そのプロジェクトに、テスト中のプロジェクトへの参照を含めます。 作るユニットテストプロジェクトが持つ名前空間を共有テスト中のプロジェクトを。 質問 .NETの世界のプロジェクトでこれを行うための受け入れられた方法はありますか、またはこれは単なる意見であり、それ以上のものはありませんか?

3
JUnitテストですべての変数を宣言することの利点/欠点
作業中の新しいコードの単体テストをいくつか作成し、コードレビューのために送りました。私の同僚の1人が、多くのテストで使用される変数をテストのスコープ外に配置した理由についてコメントしました。 私が投稿したコードは本質的に import org.junit.Test; public class FooUnitTests { @Test public void testConstructorWithValidName() { new Foo(VALID_NAME); } @Test(expected = IllegalArgumentException.class) public void testConstructorWithNullName() { new Foo(null); } @Test(expected = IllegalArgumentException.class) public void testConstructorWithZeroLengthName() { new Foo(""); } @Test(expected = IllegalArgumentException.class) public void testConstructorWithLeadingAndTrailingWhitespaceInName() { final String name = " " + …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.