私は顧客のために Rails アプリを開始しており、マインド マップを作成するか、Cucumber 仕様に直接ジャンプすることを検討しています。
Rails アプリをどのように計画しますか?
追加の質問として、Cucumber から始めるとしたら、どの時点で単体テストを作成しますか? 仕様を満たす前に?
私は顧客のために Rails アプリを開始しており、マインド マップを作成するか、Cucumber 仕様に直接ジャンプすることを検討しています。
Rails アプリをどのように計画しますか?
追加の質問として、Cucumber から始めるとしたら、どの時点で単体テストを作成しますか? 仕様を満たす前に?
私は6ステップのプロセスを持っています。
私は何かをする前に、モデルの関係と使用方法を理解することを好みます。一般的に、私はモデルを情報の一貫したチャンクを含むユニットに定義しようとします。通常、これは、アプリケーションが必要とする直交リソース (ユーザー、投稿など) を特定することから始まります。次に、これらの各リソースが絶対に必要とする情報 (属性) と潜在的に必要な情報 (関連付け)、およびその情報がどのように操作される可能性があるか (メソッド) を把握し、そこからリソースの一貫性を管理する一連のルールを定義します (検証)。 )。
他のモデルを定義するという行為は、通常、すでに行ったモデルを再考するようになるため、通常、設計を数回繰り返します。気に入ったモデル設計ができたら、モデルのリファクタリングまたは特殊化 (サブクラス化) を開始して、設計を明確にします。
移行を記述し、モデルのスケルトンを作成します。メソッドとバリデーションの最初のドラフトが実装されるまで、私は通常、テストを書きません。物事を実装する方法は、適度に検討するまで、常に明白であるとは限りません。
次はテストスイートです。バックエンドが正常であることを確認できる限り、テストの作成に何を使用したかは問題ではありません。
これは、制御フローをまとめるときです。リクエストが成功するとどうなりますか? リクエスト失敗?どのコントローラー アクションが他のコントローラー アクションにリンクしますか? 通常、コントローラーとモデル (モデルのサブクラスは数えません) の間には 1 対 1 のマッピングがあり、複数のモデル タイプを操作する必要がある状況に頻繁に遭遇します。そのために、おそらく新しいコントローラーを作成します。アプリの複雑さに応じて、フローをステート マシンとしてモデル化する場合があります。
最後にビューを作成します。モデルの関係と属性に大きく影響される UI ベースのスケッチから始めます。共通部分を抽象化してから、ビューを記述します。
UIを磨きます。CSS を作成し、リンクをリモート呼び出しに置き換えたり、必要に応じて JavaScript だけに置き換えたりします。
手順 2 と 3 を交互に行うことがあります。テストするコードを書いた直後にテストを書くのは非常に簡単です。特に、私は通常、執筆時にコンソールでテストを行っており、テストの半分はコンソールから貼り付けて作成されているためです。
また、モデル/コントローラごとに手順 4 と 5 を区分することもあります。以前の決定に戻って修正し、それらの変更を私の手順に反映させることができます。
ユーザー インターフェイスのスケッチから始めて、HTML モックアップに進みます。UI デザインが完成したら、アプリケーション内の RESTful リソースとそれらの関係を特定できます。
きゅうりの特徴だけを仕様として書くのは良くないと思います。テストに合格せずにテスト コードを記述すると、テストでエラーが発生し、後で修正するために必要な時間が長くなります。
だから私は次のことをします:
そのため、アプリケーションを実行しながら仕様を記述します。プロジェクトをクリーンに保ちながら、機敏性を維持し、プロジェクトの途中でいくつかのアイデアを変更できるようにします。