jaycfields

;; could work
(expect
  (more-of tree
           SUCCESS (tick {:foo 41} tree {})
           SUCCESS (tick {:foo 41} tree {}))
  (aidoc/compile [:test? {:key :foo :val 42}]))
  
 ;; but I strongly dislike putting fn calls in more. I'd probably use from-each
 (expect SUCCESS
  (let [tree (aidoc/compile [:test? {:key :foo :val 42}])]

jaycfields

;; move everything to runtime
(expect
  (let [user (create-user args)
        result (pred (some-function user))]
    (delete user)
    result))

jaycfields

In 2006 Martin Fowler wrote about Code Ownership. It's a quick read, I'd recommend checking it out if you've never seen it. At the time I was working at ThoughtWorks; I remember thinking "Clearly Strong makes no sense and I have no idea what scenario would make Weak reasonable". 8 years later, I find myself advocating for Weak Code Ownership within my team.

Collective Code Ownership (CCO) served me well between 2005 and 2009. Given the make-up of the teams that I was a part of I found it to be the most effective way to deliver software. Around 2009 I joined a team that eventually grew to around 9 people, all very senior developers. The team practiced Collective Code Ownership. Everyone on the team was very talented, but that didn't translate to constant agreement. In fact, we disagreed far more often than I thought we should. That experience drove me to write about the importance of

jaycfields

### Keybase proof

I hereby claim:

  * I am jaycfields on github.
  * I am jayfields (https://keybase.io/jayfields) on keybase.
  * I have a public key whose fingerprint is RETU RN T HIS. PGP. GET_  FING ERPR INT( );
     }

To claim this, I am signing this object:

jaycfields

user=> ('a 1 2)
2

jaycfields

;; top level, used only once
(defn only-used-once [r {:keys [foo]}]
  (if (even? foo)
    (+ r foo)
    r))

(defn sum-my-stuff1 [coll]
  (reduce only-used-once 0 coll))

;; anonymous fn, inline

jaycfields

I'm just a guy, who wrote a book. I have no legal department 
or official "privacy policy". It's likely that I hate spam 
more than you do, and you may receive a total of 2 emails from 
me in your life - both of which will offer my book at a discount. 
I would neither sell nor give away your email under any 
circumstances.

If you need a more official policy, I can't help you there. 
Instead, I offer the free sample without requiring your email 
address. The following links will take you directly to the 

jaycfields

assertEquals(
 "2,3", 
 a.order.w(
  stub(Product.class, s -> s.getId(), Product.id(2)),
  stub(Product.class, s -> s.getId(), Product.id(3)))
 .getProductIds());

jaycfields

Types of Tests

Before we get back to concrete examples there are a few terms we'll want to define: State Verification, Behavior Verification, Solitary Unit Test, and Sociable Unit Test. These terms have plenty of definitions available on the Internet; unfortunately, many of those definitions differ and some are in direct conflict. This chapter will define those terms for the context of this book.

Strongly Recommended Reference Material

jaycfields

Unit Test

The definition of Unit Test is quite general:

In computer programming, unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures are tested to determine if they are fit for use. [...] A unit could be an entire module, but it is more commonly an individual function or procedure. --Wikipedia