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

私はVisual Studio 2012を使用していますが、ユニットテストでこれらのパーツをモックオブジェクトに置き換えることができるように、「継ぎ目」を導入するためにクラスパラメーターにテンプレートパラメーターを追加した場合があります。 通常、C ++でどのようにシームポイントを導入しますか。テンプレートパラメーターを使用して、暗黙的なインターフェースとのいくつかの基準に基づいてインターフェースを使用したり、混合したりしますか？これを求める理由の1つは、1つのC ++ファイル（テンプレートファイルを含む、他のテンプレートも含む可能性がある）をコンパイルすると、開発者のマシンで約5〜10秒かかるオブジェクトファイルが生成されるためです。 。 VSコンパイラは、私が理解している限り、テンプレートをコンパイルするのに特に高速ではありません、テンプレートインクルードモデルのために（実際にテンプレートの定義を間接的に使用するすべてのファイルに含め、変更するたびにそのテンプレートを再インスタンス化する可能性がありますそのテンプレートとは何の関係もない）コンパイル時間に問題がある可能性があります（インクリメンタルコンパイルを行う場合）。 テンプレートを操作するときに、コンパイル時間をインクリメンタルに（そしてそれだけでなく）処理する方法は何ですか（より良い/より速いコンパイラに加えて:-)）。

13 c++  tdd  templates 

私は単体テストを行っており、クラスの1つでメソッドの1つからメールを送信する必要があるため、コンストラクター注入を使用Zend_Mailして、Zendフレームワークにあるクラスのインスタンスを注入します。 現在、一部の人々は、ライブラリが十分に安定しており、頻繁に変更されない場合、それをラップする必要はないと主張します。したがって、それZend_Mailが安定しており、変更されず、私のニーズに完全に適合すると仮定すると、そのためのラッパーは必要ありません。 次にLogger依存する私のクラスを見てみましょうZend_Mail： class Logger{ private $mailer; function __construct(Zend_Mail $mail){ $this->mail=$mail; } function toBeTestedFunction(){ //Some code $this->mail->setTo('some value'); $this->mail->setSubject('some value'); $this->mail->setBody('some value'); $this->mail->send(); //Some } } ただし、ユニットテストでは、一度に1つのコンポーネントをテストする必要があるため、Zend_Mailクラスをモックする必要があります。さらに、クラスが抽象ではなく結石に依存するようになったため、依存関係反転の原則に違反してLoggerいます。 Loggerラップせずに単独でテストするにはどうすればよいZend_Mailですか？ コードはPHPにありますが、答えはそうである必要はありません。これは、言語固有の機能というよりも設計上の問題です

13 design  object-oriented  unit-testing  tdd  solid 

私は小さなプロジェクトを継承しており、追加するすべての新しいコードの単体テストを作成して、プロジェクトを拡張し、同時に安定させたいと考えています。最初のクラス、TypedAudioCreatorはオーディオファイルを作成し、これは最初にテストし、2番目のコードを書くのが非常に簡単であることが判明しました。 しかし、書くときが来たときTypedAudioPlayer、どうやってテストできるかわかりませんでした。サウンドの再生の基本に焦点を当てた非常に小さなクラスです。 public class TypedAudioFilePlayer { public event StartedPlayingHandler StartedPlaying; public event StoppedPlayingHandler StoppedPlaying; public readonly int TimeBetweenPlays; private Queue<TypedAudioFile> _playlist = new Queue<TypedAudioFile>(); public TypedAudioFilePlayer(int timeBetweenPlays) { TimeBetweenPlays = timeBetweenPlays; } public void AddFile(TypedAudioFile file) { _playlist.Enqueue(file); } public void StartPlaying() { ThreadPool.QueueUserWorkItem(ignoredState => { while (_playlist.Count > 0) …

13 c#  tdd 

私はテスト駆動開発を実験していますが、次のような状況に陥ることが多いことがわかりました。 一部の機能Xのテストを作成します。これらのテストは失敗します。 Xを実装しようとしているときに、コードの下位層に機能Yを実装する必要があることがわかりました。そう... Yのテストを作成します。XとYの両方のテストが失敗します。 一度に異なるコードレイヤーで4つの機能を同時に使用すると、実際に実行していることに集中できなくなりました（同時に失敗するテストが多すぎます）。 テストの作成を開始する前であっても、タスクの計画にもっと力を入れることでこれを解決できると思います。しかし、いくつかのケースでは、例えば、下層のAPIをあまりよく知らなかったので、もっと深くする必要があることを知りませんでした。 そのような場合はどうすればよいですか？TDDには推​​奨事項がありますか？

13 language-agnostic  tdd 

私はTDDプロジェクトに参加しているので、この種の開発に関係する優れた慣行に可能な限りこだわります。それらの1つは、静的およびグローバルを可能な限り回避することです。 私はこの問題に直面しています。「オプション」（追加の「マイクロ記事」）をリンクできるオブジェクト「記事」があります。 私はすべてが非常に切り離されているため、基本的にオブジェクトごとに1つのクエリを作成する必要があるため、非生産的であるか、あまり多くのクエリを生成しない良いアプローチを持つ方法を理解することはできません。 私の実際の観点から、3つのオプションがあります。 1）記事内のビルド： class Article { //[...] public function getArrOption(){ //Build an array of Options instance. //return an array of Options. } } プロ：まっすぐ進む 定数：保守性：articleオブジェクトには、Optionオブジェクトの構築ロジックが含まれるようになりました。これはおそらくコードの重複につながります。 2）optionFactoryを使用する class Article { //[...] public function getArrOption(){ return OptionFactory::buildFromArticleId($this->getId()); } } プロ：ロジックの構築はArticleクラスの外にありません Const：「静的なモックは難しい」というルールを破り、Articleクラスのテストを難しくしています。 3）すべてのロジックを分離します。 //Build the array of Option instance in a …

13 php  tdd  static-access 

私は大企業で働いていますが、デスクトップLOBアプリケーションを開発するたった2人のチームです。私はかなり長い間TDDを研究してきましたが、大規模なアプリケーションでその利点を実現するのは簡単ですが、アプリケーションの規模でTDDの使用を開始する時間を正当化するのは困難です。 テストの自動化、保守性の向上などの利点を理解していますが、私たちの規模では、すべてのコンポーネントの基本的な単体テストでさえ、開発時間を簡単に倍増できます。私たちはすでに極端な締め切りに恵まれていないため、どの方向に進むべきかわかりません。それ以来、アジャイルな反復開発などの他のプラクティスが完璧になりますが、小さなチームでのTDDの生産性のトレードオフにやや引き裂かれています。 TDDの利点は、非常に厳しいスケジュールの小さなチームでの余分な開発時間に値するでしょうか？

13 tdd 

テストを作成していて、テストに合格する必要があり、独自の機能に分離する必要がある追加の機能が必要であることに気付いたとき、何をしますか？その新しい関数もテストする必要がありますが、TDDサイクルでは、テストを失敗させ、成功させてからリファクタリングするように指示されています。テストに合格しようとしているステップにいる場合、実装する必要がある新しい機能をテストするために、別の失敗したテストを開始することは想定されていません。 たとえば、関数WillCollideWith（LineSegment）を持つポイントクラスを作成しています。 public class Point { // Point data and constructor ... public bool CollidesWithLine(LineSegment lineSegment) { Vector PointEndOfMovement = new Vector(Position.X + Velocity.X, Position.Y + Velocity.Y); LineSegment pointPath = new LineSegment(Position, PointEndOfMovement); if (lineSegment.Intersects(pointPath)) return true; return false; } } LineSegment.Intersects（LineSegment）関数が必要だと気づいたとき、CollidesWithLineのテストを書いていました。しかし、この新しい機能を作成するために、テストサイクルで実行していることを停止する必要がありますか？これは「赤、緑、リファクタリング」の原則を破っているようです。 lineSegments IntersectをCollidesWithLine関数内で検出し、動作後にリファクタリングするコードを記述する必要がありますか？LineSegmentからデータにアクセスできるので、この場合はうまくいきますが、その種のデータがプライベートな場合はどうでしょうか？

13 unit-testing  tdd 

ETLプロジェクトは、SSIS、PowerCenterなどのETL（抽出-変換-ロード）ツールを使用して作成されたプロジェクトです。 これらには通常、外部ソースからのデータの読み取り、ステージングデータベースへのデータの読み込み、特定の変換の実行、最終データベースへの読み込みが含まれます。 簡単な例は、SSISを使用して、SSISを使用して学校の先生が提供するExcelファイルを読み取り、データベースにロードすることです。次に、ストアドプロシージャまたは複数のSSISパッケージを作成して各生徒の成績を計算し、そのデータをデータマート\ウェアハウスにロードします 次に、マートの上にストアドプロシージャを構築して、レポートツール（SSRS \ Excel \ etc）が視覚化を生成するために使用する出力を生成します。 このシナリオでTDDと適切な単体テストを実行する方法を理解しようとしています。ETLのテストは、主にステージングテーブルにロードされたデータがソースからのデータの正しいサブセットであることを確認することに関するものです。そのため、テストを実装すると、ETLのミニバージョンが実装されます。レポートSPの出力はテーブル自体のデータに依存するため、スクラブされたテストデータを含むデータベースを作成したとしても、メンテナンスの悪夢がなければ安定した出力データのセットを持つことはできません。 例： スプリント1：学生テーブルには名前、年齢、成績が含まれます このテーブルのテストデータを作成し、それに基づいて単体テストを作成します スプリント2：性別フィールドがテーブルに追加されます。 学生フィールドのデータを更新して性別属性を設定すると、データが変更されたため、テストケースは無効になります。しなければ、性別の列を必要とするテストケースを作成できません

12 unit-testing  sql  tdd 

私はTDDでの最初の試みであるので、これはかなりばかげた質問かもしれません。私はそれがもたらす自信とコードの一般的な構造が大好きでしたが、1クラスのおもちゃの例よりも大きなものに適用し始めたとき、私は困難に直面しました。 ある種のライブラリを作成しているとします。あなたはそれが何をしなければならないか、それがどのように実装されるべきかについての一般的な方法を知っています（アーキテクチャ上）、しかしあなたはあなたがコードとしてあなたのパブリックAPIに変更を加える必要があることを「発見」し続けます。おそらく、このプライベートメソッドを戦略パターンに変換する必要があり（テストでモックされた戦略を渡す必要があります）、おそらく責任をあちこちに置き忘れて、既存のクラスを分割する必要があります。 既存のコードを改良する場合、TDDは非常に適しているように見えますが、最初からすべてを記述する場合、テストを作成するAPIは、事前に大きな設計を行わない限り、少し「ぼやけ」ます。シグネチャ（およびその部分の動作）が変更されたメソッドで既に30のテストがある場合はどうしますか？それは一度追加すると変更する多くのテストです。

12 tdd 

私は新しいプロジェクトを開始し、TDDを使用して設計を推進することに非常に一生懸命取り組んでいます。私は何年もプッシュしてきましたが、ついにこのプロジェクトに余分な時間を費やして、それを適切に行う方法を学びながら、それを使用することを承認しました。 これは、既存のシステムに結び付ける新しいモジュールです。現在、すべてのデータアクセスはWebサービスを介して行われます。Webサービスは、ほとんどの場合、データベースストアドプロシージャの単なる薄いラッパーです。 1つの要件は、特定のストアについて、このアプリケーションに対して有効と見なされるすべての発注書を返すことです。出荷日が店舗のオープン日から特定の範囲内にある場合、POは有効であると見なされます（これは新しい店舗の場合です）。 上記の制約が与えられた場合、このストアに適用できるダースを取得するためだけに100万のPOを戻すつもりはないので、このロジックをアプリケーションコードに入れることはできません。 日付範囲をGetValidPOsプロシージャに渡し、それらの値を使用して有効なPOを返すことができると考えていました。しかし、有効なPOと見なされるものに別の要件を追加するとどうなりますか？ そして、どのようにこれをテストし、機能し続けることを確認しますか？ORMを使用していないため、起こりそうにありません。また、テストでDBを呼び出すことはできません。 立ち往生しています。 私の考えでは、有効なデータを返すモック、不良データを返すモック、不良データが発生した場合にローカルリポジトリに例外をスローさせ、無効なデータがGetValidPOs procによって返された場合に例外がスローされることをテストしますテストで使用されるモック）。 これは理にかなっていますか？または、より良い方法はありますか？ 更新： EFを使用できるようです。ストアドプロシージャと複数のデータベースにデータを散在させることの困難さに依存しながら、使用方法を把握し、テスト可能にする必要があります。

12 tdd  stored-procedures 

最近、ファクトリーメソッドをTDDしていました。その方法は、単純なオブジェクト、またはデコレータでラップされたオブジェクトを作成することでした。装飾されたオブジェクトは、いずれもStrategyClassを拡張するいくつかのタイプのいずれかです。 私のテストでは、返されたオブジェクトのクラスが期待どおりかどうかを確認したかった。単純なオブジェクトosが返されたときは簡単ですが、デコレータでラップされたらどうしますか？ ext/Reflectionラップされたオブジェクトのクラスを見つけるために使用できるようにPHPでコーディングしますが、物事を複雑にしすぎているようで、TDDのルールにやや反対しています。 代わりにgetClassName()、StrategyClassから呼び出されたときにオブジェクトのクラス名を返すように導入することにしました。ただし、デコレータから呼び出された場合は、装飾されたオブジェクトの同じメソッドによって返された値を返します。 より明確にするためのいくつかのコード： interface StrategyInterface { public function getClassName(); } abstract class StrategyClass implements StrategyInterface { public function getClassName() { return \get_class($this); } } abstract class StrategyDecorator implements StrategyInterface { private $decorated; public function __construct(StrategyClass $decorated) { $this->decorated = $decorated; } public function getClassName() { return $this->decorated->getClassName(); } …

12 php  tdd 

チームで協力して、C＃.NETを使用して開発された中規模のデスクトップアプリケーションを開発する必要があります。これに先立ち、私は単体テストとテスト駆動開発を適用していません。ユニットテストC＃アプリケーション用の多くのツールとフレームワークが存在することを認識しています。今のところ、NunitとVisual Studioに統合された単体テスト機能を知っています。 知りたいのですが、この2つはどのように比較されますか？

12 unit-testing  comparison  tdd  visual-studio  nunit 

もともと、テストを作成するのは開発者の義務ですが、多くの場合/ e-mature開発者では、これらのケースが80％のカバレッジでさえないことに気付きました。 開発者ではなく、特定のプロジェクトのすべてのテストを作成するQA担当者がいますか？ それに短所はありますか？

12 development-process  tdd 

最終的に（そしてうまくいけば）TDDのみを開始するための単純な単体テストを作成する方法を学んでいます。今のところ、問題の原因を調べるために、すでに記述されているコードのテストを記述しようとしています。これはその1つです。 私がこの単純なクラス（Typescript-> JavaScript）を持っているとしましょう： class PrivateStuff { greeting: string; private _thisIsPrivate; constructor(isPrivate: boolean) { this._thisIsPrivate = isPrivate; } setPrivate(option) { this._thisIsPrivate = option; console.log("_thisIsPrivate changed to : " + option); } getPrivate() { console.log("_thisIsPrivate is : " + this._thisIsPrivate); return this._thisIsPrivate; } } そして私はそれをこのように使用します： let privateStuff = new PrivateStuff(false); let buttonSet …

12 unit-testing  tdd 

多くの人にパッチなどを提出してもらいたいと思う/期待するオープンソースプロジェクトを開始したいとしましょう。厳密なTDDアプローチをとることは実行可能ですか？共同作業者がパッチを提出するたびに品質テストを作成することを期待/信頼できるか？ 私が考えていた1つのことは、個々のバグレポートと機能リクエスト用のテストスイートを作成し、すべてのパッチ/プルリクエストがテストに合格することを要求しますが、その時点で機能/バグ修正を書く方が良いようです自分。 私が知る限り、TDDを使用する（または少なくともテストを書く）主要なオープンソースプロジェクトのほとんどは、個人またはチームによって純粋に記述されているようで、TDDなどのプラクティスを実施するのは簡単です。

11 open-source  tdd  collaboration