53

だから、私はClojure.Specをどんどん深く掘り下げています。

私がつまずいたのは、スペックをどこに置くかということです。次の 3 つのオプションが表示されます。

グローバル スペック ファイル

私がオンラインで見つけたほとんどの例ではspec.clj、メインの名前空間で必要になる大きなファイルが 1 つあります。すべての「データ型」と機能のすべてと機能を備えています(s/def)。(s/fdef)

プロ：

  • すべてを支配する 1 つのファイル

反対:

  • このファイルは大きくなる可能性があります
  • 単一責任の原則に違反していますか?

プロダクション名前空間の仕様

(s/def)and(s/fdef)を本番コードのすぐ隣に置くことができます。そのため、実装と仕様は同じ名前空間に共存します。

プロ：

  • 実装と仕様のコロケーション
  • 1 つの名前空間 - 1 つの懸念事項?

反対:

  • 本番コードが乱雑になる可能性があります
  • 1 つの名前空間 - 2 つの懸念事項?

専用スペック名前空間構造

次に、仕様は第 3 の種類のコード (本番とテストの次に) ではないかと考えました。したがって、次のような名前空間の独自の構造に値する可能性があります。

├─ src
│  └─ package
│     ├─ a.clj
│     └─ b.clj
├─ test
│  └─ package
│     ├─ a_test.clj
│     └─ b_test.clj
└─ spec
   └─ package
      ├─ a_spec.clj
      └─ b_spec.clj

プロ：

  • 仕様専用の (しかし関連する) 名前空間

反対:

  • 正しい名前空間を調達して要求する必要があります

アプローチの1つを経験したのは誰ですか?
別のオプションはありますか？
さまざまなオプションについてどう思いますか?

4

3 に答える 3

22

私は通常、スペックが記述している名前空間と並んで、仕様を独自の名前空間に入れます。一貫した命名規則を使用している限り、名前の付け方は特に問題ではありません。たとえば、私のコードが にある場合、my.app.fooスペックは に入れますmy.app.foo.specs。

仕様のキー名は、仕様の名前空間ではなく、コードの名前空間にあることが望ましいです。これは、キーワードで名前空間エイリアスを使用することで簡単に実行できます。

(ns my.app.foo.specs
  (:require [my.app.foo :as f]))

(s/def ::f/name string?)

すべてを 1 つの巨大な仕様の名前空間に入れようとするのは避けたいと思います (悪夢です)。同じファイル内の仕様コードのすぐそばにそれらを配置することは確かにできますが、それは読みやすさの IMO を損ないます。

すべての仕様の名前空間を別のソース パスに配置することもできますが、コードを配布したいが仕様は配布したくない、またはその逆でない限り、そうしても実際の利点はありません...それが何なのか想像するのは難しいですだろうけど。

于 2016-06-21T13:27:05.023 に答える