テストカバレッジはどうなりましたか？

キーボードの前に座って決定しようとしている場合 少しのコードをテストする必要があるかどうかにかかわらず、あなたはすでに間違った道を進んでいます。常にデフォルトで「テストする」に設定する必要があります。些細なトーンのテストに思えても、テストを書いてください。

コードの記述が簡単な場合は、テストが簡単なはずです。そして、複雑なコードは、書いた直後ほど些細なことではありません。 今から6か月後もささいなことのように見えることをどうやって知っていますか？

しかし、オーバーテストしたくない

巨大なテストスイートは、それ自体が問題になる可能性があります。実行に20分かかるテストは、常に実行するわけではないため、テストをまったく実行しないのと同じくらい優れています。 （あなたはそうすると言いますが、私はあなたがそうしないことを知っています）。さらに悪いことに、脆弱なテストが多すぎると、リファクタリングが以前よりもさらに苦痛になるため、実行しません。最終的には、ほとんどの小説よりも長い方法になります。

これは私の以前のポイントと矛盾しますか？必ずしも。テストは常にコードのインターフェースに焦点を当てる必要があります 、その実装ではありません 。例：

class Cart
  def initialize(item_params)
    @line_items = Array(item_params).map {|item| LineItem.new(item[:name], item[:price])}
  end

  def total
    @line_items.sum(&:price)
  end
end

ここのコードは、両方のCartをテストする必要があるように感じます。 クラスとLineItem クラス。しかし、LineItemです 他の何かによって使用されるクラス？ Cartの実装の詳細だけの場合 、そして外の世界にさらされていないので、実際にいくつのテストが必要ですか？からだけテストすることはできません。 あなたのCart クラス？

リファクタリングによって抽出されたクラスは、多くの場合、独自のテストスイートを必要としません。これらは単なる実装の詳細です。 これらの追加のテストが必要になるのは、それらが単独で使用される場合のみです。

パブリックインターフェイスに対する優れたテストスイートを使用すると、すべてのテストを書き直すことなく、実装を柔軟に変更できます。これは、平均的なものを書くよりもはるかに少ない労力で行うことができます。 オブジェクトの実装に対するテストスイート。