0

サイト内を検索しましたが、答えが見つかりませんでした..

プロジェクトをゼロから始めたいのですが、顧客から製品の HTML モックアップを受け取り、TDD アプローチでそれを行うように依頼されました。

普段はフロントエンドとバックエンドの両方の設計・開発を担当していましたが、モックアップをいただいたのは初めてです。これは、コンサルテーション用のソフトウェアを開発する私の好みのスタイルではありません (私は通常、モデル レイヤー、次にビュー、そしてそれらを統合するためのコントローラーから始めます)。

だから私の質問は：

1-基本的に、問題にどのように対処すればよいですか? ビューレイヤーを持っている方が良いことはわかっていますが、ビューを好みのテンプレート言語に適応させたいと考えています。

2- TDD アプローチで行う必要があります。たとえば、Selenuim テスト ツールを使用して「機能テスト」を行うには、MockUp を使用するのが最適なシナリオだと思います。私は正しいですか??

4

1 に答える 1

0

短い応答は次のとおりです。

  1. 問題の定義をできるだけ形式的に書く
  2. 1 つ以上のテスト フレームワークを選択し、テストを記述します。単純化:
    1. バックエンドの単体テスト
    2. フロントエンドの機能テスト
  3. ループの開始: 設計、コード、テスト
  4. コミッターと定期的にレビュー

モックを実現するために必要なすべての View Technology を使用できます。HTMLです...

より詳細な HTML モックアップは、ユース ケース(UC) とビジネス要件(BR) を定義するのに役立ちます。UC と BR から、完全な要件仕様の最初のドラフトと、開発者 (自分) の観点からのシステムおよびアーキテクチャ設計を定義できます。

BR のすべての機能要件には、あなたが言及した Selenium などを使用して実行可能な機能テストが必要であり、それぞれに単体テストを定義できるいくつかの細かい粒度の要件に分解する必要があります。TDD アプローチに従って、バックエンドを構築して、すべての単体テストとロールアップ、すべての機能テストに合格するようにします。

単一の BR のバックエンドが完成したら、好みのビュー テクノロジで対応する html モックを具体化し、技術環境で機能テストを実行してから統合環境で実行できます。

これらのテストは、継続的インテグレーションを使用して自動的に実行できます。

UC のすべての BR が機能テストと単体テストに合格したら、コミッターにユース ケースを送信してユーザーの承認を得て、フィードバックを得ることができます。

すべてのステップで、設計段階までのループバックを考慮する必要があります。UC、BR、および単体テスト間のすべての依存関係を追跡すると (たとえば、スプレッドシートのトレーサビリティ マトリックスを使用して)、ループバックの影響を特定して制限し、限られたコード ベースへのコード変更に対応できるはずです。

于 2012-04-07T14:22:27.880 に答える