人们测试他们的 clojure.spec 规格是否很常见？

Question

我正在自学 Clojure，并且我一直在做一个简单的玩具项目来创建一个 Kakebo（日语预算工具）供我学习。首先，我将使用 CLI，然后是 API.

因为我刚刚开始，所以我已经能够“理解”规范，这似乎是 clojure 中用于验证的一个很好的工具。所以，我的问题是：

人们测试自己编写的规范？
我像下面的代码一样测试了我的。有更好的建议吗？

据我所知，有一些方法可以通过生成测试自动测试功能，但对于基本规格，这种测试是一种好的做法吗？

规格文件：

(ns kakebo.specs
  (:require [clojure.spec.alpha :as s]))


(s/def ::entry-type #{:income :expense})
(s/def ::expense-type #{:fixed :basic :leisure :culture :extras})
(s/def ::income-type #{:salary :investment :reimbursement})
(s/def ::category-type (s/or ::expense-type ::income-type))
(s/def ::money (s/and double? #(> % 0.0)))
(s/def ::date (java.util.Date.))
(s/def ::item string?)
(s/def ::vendor (s/nilable string?))
(s/def ::entry (s/keys :req [::entry-type ::date ::item ::category-type ::vendor ::money]))

测试文件：

(ns kakebo.specs-test
  (:require [midje.sweet :refer :all]
            [clojure.spec.alpha :as s]
            [kakebo.specs :refer :all]))

(facts "money"
       (fact "bigger than zero"
             (s/valid? :kakebo.specs/money 100.0) => true
             (s/valid? :kakebo.specs/money -10.0) => false)
       (fact "must be double"
             (s/valid? :kakebo.specs/money "foo") => false
             (s/valid? :kakebo.specs/money 1) => false))

(facts "entry types"
       (fact "valid types"
             (s/valid? :kakebo.specs/entry-type :income) => true
             (s/valid? :kakebo.specs/entry-type :expense) => true
             (s/valid? :kakebo.specs/entry-type :fixed) => false))

(facts "expense types"
       (fact "valid types"
             (s/valid? :kakebo.specs/expense-type :fixed) => true))

作为最后一个问题，如果我尝试以下导入，为什么我无法访问规范：

(ns specs-test
  (:require [kakebo.specs :as ks]))

(fact "my-fact" (s/valid? :ks/money 100.0) => true)

Answer 1

无论我是否使用规范，我个人都不会编写与代码紧密耦合的测试。这几乎是对每一行代码的测试——这可能很难维护。

规范中有几个看起来是错误的地方：

;; this will not work, you probably meant to say the category type 
;; is the union of the expense and income types
(s/def ::category-type (s/or ::expense-type ::income-type))

;; this will not work, you probably meant to check if that the value 
;; is an instance of the Date class
(s/def ::date (java.util.Date.))

通过将现有的原子规范组合成在应用程序中执行繁重工作的更高级别的规范，您确实可以从规范中获得很多好处。我会测试这些更高级别的规格，但通常它们可能落后于常规功能，并且规格可能根本不会公开。

例如，您将 entry 定义为其他规格的组合：

(s/def ::entry (s/keys :req [::entry-type ::date ::item ::category-type ::vendor ::money]))

这适用于验证所有必需的数据是否存在以及生成使用此数据的测试，但数据中存在一些传递依赖性，例如 :expense 不能是 :salary 类型，所以我们可以将其添加到 entry 规范中：

;; decomplecting the entry types
(def income-entry? #{:income})
(def expense-entry? #{:expense})
(s/def ::entry-type (clojure.set/union expense-entry? income-entry?))

;; decomplecting the category types
(def expense-type? #{:fixed :basic :leisure :culture :extras})
(def income-type? #{:salary :investment :reimbursement})
(s/def ::category-type (clojure.set/union expense-type? income-type?))

(s/def ::money (s/and double? #(> % 0.0)))
(s/def ::date (partial instance? java.util.Date))
(s/def ::item string?)
(s/def ::vendor (s/nilable string?))

(s/def ::expense
  (s/cat ::entry-type expense-entry?
         ::category-type expense-type?))

(s/def ::income
  (s/cat ::entry-type income-entry?
         ::category-type income-type?))

(defn expense-or-income? [m]
  (let [data (map m [::entry-type ::category-type])]
    (or (s/valid? ::expense data)
        (s/valid? ::income data))))

(s/def ::entry
  (s/and
   expense-or-income?
   (s/keys :req [::entry-type ::date ::item
                 ::category-type ::vendor ::money])))

根据应用程序甚至上下文的不同，您可能有描述相同数据的不同规范。上面我将 expense 和 income 组合成 entry 这可能有利于输出到报告或电子表格，但在应用程序的另一个区域，您可能希望将它们完全分开以进行数据验证;这确实是我使用规范最多的地方——在系统的边界，例如用户输入、数据库调用等。

我对规范进行的大部分测试都在验证进入应用程序的数据方面。我唯一一次测试单个规范是他们是否有业务逻辑而不仅仅是数据类型信息。

人们测试他们的 clojure.spec 规格是否很常见？

Is it common for people to test their clojure.spec specs?

unit-testing

clojure

midje

clojure-testing

clojure.spec