Skip to content

Instantly share code, notes, and snippets.

Jay Fields jaycfields

Block or report user

Report or block jaycfields

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
View foo.clj
;; 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}])]
View some.clj
;; move everything to runtime
(expect
(let [user (create-user args)
result (pred (some-function user))]
(delete user)
result))
View primary.md

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 <a href="http://blog.jayfields.com/2011/01/compatible-op

View gist:4ac5b53a87dc2e342df0
### 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:
View defn-recur.clj
;; 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
jaycfields / privacy-policy.txt
Last active Aug 29, 2015
Privacy Policy for Twitter & #wewut
View privacy-policy.txt
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
View example.java
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());
View types.md

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

View solitary-sociable-ut.md

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

You can’t perform that action at this time.