a tutorial introduction - eunmin/Midje GitHub Wiki

.lein/profiles.clj 파일에 아래와 같이 추가합니다 :

{:user {:plugins [[lein-midje "3.0.0"]]}}

작업 디렉토리를 하나 준비하고 아래와 같이 타이핑합니다 :

% lein new midje quux

Lein-midje는 샘플 테스트와 소스 코드가 포함된 디렉토리 구조를 생성합니다 :

Midje는 소스 파일과 테스트 파일을 한 파일에 섞어 놓지만 이 튜토리얼에서는 일반적인 방법에 따라 파일을 분리할 것입니다.

project.clj 파일에는 Midje를 개발 환경에서 사용할 수 있도록 의존성에 포함하고 있습니다 :

(defproject quux "0.0.1-SNAPSHOT"
  :description "Cool new project to do things and stuff"
  :dependencies [[org.clojure/clojure "1.4.0"]]
  :profiles {:dev {:dependencies [[midje "1.5.1"]]}})  ;; <<==

과거의 어떤 이유로 Midje는 이상한 네임스페이스를 가집니다 :

(ns quux.t-core
  (:use midje.sweet)               ;; <<==
  (:require [quux.core :as core]))

여러분이 책을 쓰고 conj를 설명하기를 원한다고 가정합시다. 여러분은 "conj appends its element to the end of a vector but to the front of a list or lazy sequence" 라고 작성할지도 모릅니다. 그리고 아래와 같이 3개의 예제를 작성할 것입니다 :

(conj [1 2] 3)           ;; [1 2 3]
(conj '(1 2) 3)          ;; (3 1 2)
(conj (map inc [0 1]) 3) ;; (3 1 2)

또는 아래와 같이 작성할 수 도 있습니다 (the style of my own Functional Programming for the Object-Oriented Programmer):

user=> (conj [1 2] 3)
[1 2 3]
user=> (conj '(1 2) 3)
(3 1 2)
user=> (conj (map inc [0 1]) 3)
(3 1 2)

또는 이런식으로 작성 할 수 도 있지요 (the style of The Joy of Clojure):

(conj [1 2] 3)
;=> [1 2 3]
(conj '(1 2) 3)
;=> (3 1 2)
(conj (map inc [0 1]) 3)
;=> (3 1 2)

예제(see also)에 있는 화살표는 친숙합니다. 그래서 여기서 화살표를 쓰는 것은 적합합니다. 그 이유는 왼쪽에서 오른쪽으로 나아가는 언어를 사용하는 사람들은 똑같은 방법으로 생각할 수 있기 때문입니다. (영어로된 달력을 보세요.) 그래서 conj 구문이 왼족에 있는 것은 직관적입니다 : 먼저 평가된 후에 결과가 나옴. 또 화살표는 시간 흐름이나 흥미로운 어떤 일을 가리킬때 사용하는 것과 관련되어 있기 때문에 자연습니다. 그리고 적어도 화살표는 두 개의 형태를 시각적으로 분리해줄 수 있습니다.

Midje checkables은 일반적으로 아래 예제에 있는 예제를 따릅니다 :

    ;; the following pseudo-expressions are checkables
    (conj [1 2] 3) => [1 2 3]
    (conj '(1 2) 3) => '(3 1 2)
    (conj (map inc [0 1]) 3) => '(3 1 2)

여기서 많은 사람들은 Lisp 같지 않은 이상한 문법을 볼수 있는데 클로저는 대안으로 다른 문법들을 제공 한다 :

    (expect (conj [1 2] 3) => [1 2 3])
    (expect (conj '(1 2) 3) => '(3 1 2))
    (expect (conj (map inc [0 1]) 3) => '(3 1 2))

(화살표는 의미적으로 적절합니다: 다른 종류의 화살표도 있습니다.)

하지만 expect는 거의 사용되지 않기 때문에 Midje 사용자들은 이상해 보일것입니다.

Checkables는 따로 체크를 위해 사용할 수 없습니다. Midje에 있는 가장 작은 단위의 checkable은 fact입니다. 이 이름은 우리가 진짜로 원하는 것 이 무엇인가에 대한 행동입니다.(: 강력한 수학적 사실에 대한 요청을 만들기 위한) 우리는 "모든 문자열 s와 모든 정규식 re는 (str/split s re)는 ... 하다.를 만족한다"와 같은 강한 문법을 만들기를 원합니다.

그리고 사실 우리는 요구 사항 같은 것을 만들 수 있습니다. 하지만 우리는 수학자들이 하는 것처럼 증명할 수 없습니다. 우리가 일반적인 프로그래밍에서 할 수 있는 최선의 방법은 요구 사항이 성공으로 확인 될 정도로 자신있을 때까지 충분한 예제를 많이 제공하고 그것을 확인하는 일입니다. 아래 예제를 보세요 :

(fact "`split` splits strings on regular expressions and returns a vector"
  (str/split "a/b/c" #"/") => ["a" "b" "c"]
  (str/split "" #"irrelevant") => [""]
  (str/split "no regexp matches" #"a+\s+[ab]") => ["no regexp matches"])

It's Midje's job to check the checkables (to try to confirm the examples) and report helpfully when they fail.

Let's be realistic

I personally try to think of checkables as examples of more general facts. Other people like to think of them as the facts themselves. Those people tend to use facts instead of fact:

(facts "about `split`"
  (str/split "a/b/c" #"/") => ["a" "b" "c"]
  (str/split "" #"irrelvant") => [""]
  (str/split "no regexp matches" #"a+\s+[ab]") => ["no regexp matches"])

Other people think all this talk about facts is nonsense and treat fact as nothing more than a way of grouping checkables and nested facts, similar to context in Ruby test frameworks. Midje is agnostic about how you think about its names. If you want to treat "fact" as a misspelling of "test", go ahead.

여러분은 정상적으로 동작하는 clojure.string/split를 테스트하고 싶지는 않을겁니다. 그래서 버그를 가지고 있는 간단한 함수를 봅시다.

시나리오는 다음과 같습니다 : 클로저 프로그래머가 왔다. 그녀는 시퀀스의 첫번째 항목을 리턴하는 함수를 작성하려고 한다. 만약 시퀀스가 비어있다면 기본값을 리턴하게 만드려고 합니다.

(defn first-element [sequence default]
  (if (nil? sequence)
    default
    (first sequence)))

클로저는 Lisp 처럼 nil과 ()를 같이 취급하지 않기 때문에 이 함수에는 버그가 있습니다. 그래서 그녀는 클로저 프로그래머들이 empty?를 사용하는 것 처럼 그걸 사용하게 되었습니다.

하지만 그녀는 조심스러운 프로그래머이기 때문에 그녀는 정상적인 경우 뿐만아니라 다양한 종류의 시퀀스가 빈 경우에 대비하기로 하였습니다. :

(facts "about `first-element`"
  (fact "it normally returns the first element"
    (first-element [1 2 3] :default) => 1
    (first-element '(1 2 3) :default) => 1)

  ;; I'm a little unsure how Clojure types map onto the Lisp I'm used to.
  (fact "default value is returned for empty sequences"
    (first-element [] :default) => :default
    (first-element '() :default) => :default
    (first-element nil :default) => :default
    (first-element (filter even? [1 3 5]) :default) => :default))

두 개의 서로 다른 checkable를 위해서 nested facts를 사용한것을 보세요. 조심스럽게 한 덕분에 몇개의 버그를 체크할 수 있었습니다 :

(Midje가 사용하는 터미널 색상을 보여주기 위해서 스크린 샷을 사용했습니다. 원하지 않으면 colorizing을 끌 수 있습니다.)

버그를 수정하기 전에 lein midje를 수행할 때 JVM, Clojure, Midje를 로드하기 때문에 생기는 느림 현상을 피할 수 있는 방법을 알려드리겠습니다.

많은 테스팅 툴들은 autotest를 제공 합니다. autotest 툴은 모든 것을 체크할 수 있는 하나의 테스트를 가지고 시작합니다. 하지만 종료되지 않고 테스트 디렉토리와 소스의 변경을 감지합니다. 변경이 감지되면, 변경 된 파일과 그 파일의 의존하고 있는 다른 파일들을 직간접적으로 리로드 합니다. (Midje의 경우 의존성은 각 파일에 있는 ns구문에 표시되어 있습니다.)

Lein-midje의 autotesting은 은 커맨드라인에서 시작할 수 있습니다 :

690 $ lein midje :autotest

하지만 repl 툴을 사용할때는 더 편리한 방법이 있습니다.

이렇게 하면 됩니다 :

I'll let you explore Midje's in-repl documentation on your own. For now, type the following:

Notice that you still have the repl prompt, so you can combine autotesting with interactive repl development. For example, you can double-check results:

Go ahead and fix the source. Here's what happened as I did, typo and all.

Midje doesn't use = to compare the left-hand to right-hand sides, but rather its own extended equality. There are various small – and two large – differences between equality and extended equality.

The first of the large differences is the handling of regular expressions. Equality is a pretty useless concept for them, since regular expressions aren't even equal to non-identical copies:

user=> (= #"a.b" #"a.b")
false

In a Midje checkable, a regular expression on the right-hand side causes a check for a partial match:

user=> (fact "O wad    some pow'r" => #"wad\s+some")
true

That is, the checking is done with re-find.

The larger of the two large differences is the handling of functions on the right-hand side. Under extended equality, the actual result isn't compared to the function. Instead it is passed to the function and the result is checked for "truthiness" (that is, any value other than nil or false). Here's a simple example:

user=> (fact (+ 1 2) => even?)

FAIL at (NO_SOURCE_PATH:1)
Actual result did not agree with the checking function.
        Actual result: 3
    Checking function: even?
false

Midje comes prepackaged with useful functions, called checkers, for your checkables. The two most used are probably truthy and falsey. Consider this expression:

(some even? [1 5])

The result of that expression is nil, so we could write this fact:

(fact
  (some even? [1 5]) => nil)

That works, but it does a poor job of expressing intent. Most often, we don't care specifically that the result is nil — we care that the result counts as false. So this is better:

(fact
  (some even? [1 5]) => falsey)

Note: you can also negate the arrow to force a check for inequality:

(fact
  (some even? [1 5]) =not=> truthy)

One disadvantage of truthy and falsey is that checkables using them often do not read clearly because they don't match the way we normally speak or write. Consider [1 3 5 8]. Most people would be more likely to say "The array has an [or "some"] even element" than "A search for some even element would yield a truthy value." We can use extended equality to match the way people speak:

(fact
  [1 3 5 8] => #(some even? %)   ; or...
  [1 3 5 8] => (partial some even?))

Unless you're a huge fan of higher-order functions and can grasp their meaning immediately, that looks kind of awkward. Midje provides a checker that looks nicer:

(fact
  [1 3 5 8] => (contains even?))

This works because contains interprets its arguments using extended equality (so that functions are given actual results as arguments). However, it and other collection checkers are probably most often used with non-function values. Here are two examples. I've made them fail so you can see what failure output looks like:

user=> (fact {:a 1, :b 2} => (just {:a 1, :CCC 333}))

FAIL at (NO_SOURCE_PATH:1)
Actual result did not agree with the checking function.
        Actual result: {:a 1, :b 2}
    Checking function: (just {:CCC 333, :a 1})
    The checker said this about the reason:
        Best match found: {:a 1}
false

user=> (fact [1 2 3 4 5] => (contains [1 2 4]))

FAIL at (NO_SOURCE_PATH:1)
Actual result did not agree with the checking function.
        Actual result: [1 2 3 4 5]
    Checking function: (contains [1 2 4])
    The checker said this about the reason:
        Best match found: [1 2]
false

The second example fails because contains by default looks for a contiguous subsequence. That can be overridden:

user=> (fact [1 2 3 4 5] => (contains [1 2 4] :gaps-ok))
true

Test-driven design can be done either bottom up (in a way reminiscent of traditional Lisp repl-driven development) or top down (as described in Growing Object-Oriented Software, Guided by Tests, one of the strong early inspirations for Midje). Since there are various paths through this user documentation, I'll point you to this introduction if you're interested in learning about how Midje views the top-down approach in a functional language.

With Midje, I've aimed to support bottom-up design, top-down design, and (most importantly) a smooth alternation between the two. I've also aimed to combine the ease of repl-based development with the long-term value of putting tests in files. To judge how well I've met my goals, you'll have to put Midje to use.