ruby-on-rails - Rails、SRP、単体テスト

Question

前文

SRP を念頭に置いてアプリを構築しようとするのはこれが初めてであり、データアーキテクチャ (ActiveRecord) から始めてそれに合わせてアプリを構築するのではなく、実際にテストを使用してサイトのコードを駆動しようとしています。

しかし、私は問題に直面しています。私は Destroy All Software のスクリーンキャストをたくさん購読して見てきました。理論的には彼の説教は好きですが、実際には機能させるのに苦労しています。

当面の問題

私のアプリの主な機能は、場所に基づいてプロファイルを検索することです。そこで、そのための簡単な Cucumber 機能を作成します (目前のタスクを簡素化するために、当面は意図的にルート/コントローラーなどを除外します)。

検索機能:

Feature: Search for profiles

  Scenario: By zipcode
    When I search for 90210
    Then I will see profiles near 90210

search_steps.rb:

When /^I search for 90210$/ do
  @profiles = ProfileSearch.new.near_location(90210).all
end

Then /^I will see profiles near 90210$/ do
  pending # express the regexp above with the code you wish you had
end

問題ありません。仕様に進みます。

profile_search_spec.rb:

require_relative '../../app/services/profile_search'

describe ProfileSearch do  
  it "finds nearby profiles"
  it "does not find far away profiles"
end

profile_search.rb:

class ProfileSearch
end

私が ProfileSearch クラスを使用した理由はいくつかあります。

できるだけ多くのビジネスロジックを ActiveRecord の外に移動することは正しいことのように思えます (単一責任の原則)。
PORO はテストを高速化します (Rails をロードしません)。
近い将来、ElasticSearch または Solr を使用する予定であり、インターフェイスを同じままにしたいと考えています。

次に何をすべきかよくわかりません。ProfileSearch明らかにProfileモデルによって異なりますが、これは ActiveRecord になると確信しています。

問題は、仕様を作成してビルドProfileを開始し、テストでRailsのロードを開始するだけですか? これは最も簡単なオプションのように思えますが、何かが間違っているようです。アプリがまだ具体的に要求していない動作を設計および構築するように感じます。フィールド、リレーション、ストレージなどについて考える必要がありますが、これらは現在、私のアプリが気にする必要はありません。

Profileまたは、仕様内のすべての呼び出しにスタブ/モックを使用ProfileSearchし、正しいメソッドが呼び出されていることを確認する必要がありますか? そのときは動作を実際にテストしていないため、これも間違っているようです。同じ動作が予想される場合でも、Solr または ElasticSearch に切り替えるときにテストを書き直す必要があります。

それとも、当分の間 ActiveRecord を使用しないが、Bob おじさんが wiki のものを構築するときに示したように、すべての適切なメソッドに正しく応答する、実際に機能する Profile モデルを実際に作成する必要がありますか? これは理論的には最良のアプローチのように思えますが、将来的に ActiveRecord を使用することを考えると、かなり冗長に思えます。

または...それをファックして、ActiveRecordモデルのすべてをスローします:\

頭の中に浮かんでいるパターン、原則、ベストプラクティスが多すぎて、どうすればよいかわかりません。

あなたならどうしますか？

ruby-on-rails - Rails、SRP、単体テスト

1 に答える 1

Related

Reference