> What are the cons of using midje? Any reason I shouldn't migrate all
> my unit testing to it?
I'm biased, but I think Midje is ready for production use. There's a smooth
migration path because Midje uses the same reporting as clojure.test, so you
can mix styles in the same file and still use
I love Midje and think migrating all the tests to it is a great idea.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
Thanks, Brian! I obviously didn't understand the nature of the
provided form. That's really cool notation! This is exactly what I
want.
What are the cons of using midje? Any reason I shouldn't migrate all
my unit testing to it?
Thanks!
Alyssa
On Dec 22, 9:46 am, Brian Marick wrote:
> On Dec
On Dec 22, 2010, at 6:52 AM, Alyssa Kwan wrote:
> The issue is where do I specify that:
> (undo-fn ...patch...) => (fn [] (reset! visible-evidence-of-a-side-
> effect :happened!))
The code you quoted is that specification. It doesn't matter that undo-fn is a
multimethod.
Here's what the notat
The issue is where do I specify that:
(undo-fn ...patch...) => (fn [] (reset! visible-evidence-of-a-side-
effect :happened!))
undo-fn is a multimethod in my design, which requires a corresponding
defmethod for each patch type. I need to create one for the scope of
the test, but defmethod by defin
I'd like to discuss this design approach. (It's unrelated to the
testing issue.) I avoided this design because the undo-fn is
determined at do-patch! time. The use case is for a persistent system
like Git where patches may be undone long after being done - e.g. long
after the patch is written to
I think I misunderstand the issue, because this works for me:
(ns midje.util.git
(:use [midje.sweet]))
;; Code except for undo-patch is the same as before.
;; ...
;; I pulled remove-patch out of undo-patch because I was
;; getting a screwy read error I didn't want to figure out
;; at 5 in the
Hi,
maybe a different approach could be to use a richer datatype than a function,
which carries both: the command and the undo command.
(deftype Command [action undo])
Then you could do something like:
(defn do-patch!
[command args]
(dosync
(let [patch {:command command :args (vec args
Hi Alex,
Unfortunately the some-fn has to be created at the top level; it has
to be a var to be dynamically bindable, and Midje (and AFAIK, all
other mocking frameworks) use dynamic binding.
Here's what I came up with, using clojure.contrib.mock.test-adapter:
(deftest test-undo-patch!-calls-undo
So I lied, I couldn't resist doing just one more:
(defn some-fn [] nil)
(fact "calls the anonymous function that undo-fn returns"
(undo-patch ...patch...) => @patches-
(provided
(undo-fn ...patch...) => some-fn
(some-fn) => nil))
The two provided statements are mboth mocking and stub
Hi Alyssa,
Using the midje library I was able to do your first test. I'm pretty tired
so I this might be it for the night.
(fact "throws an error if can't resolve undo function"
(undo-patch [2]) => (throws IllegalArgumentException "No method in
multimethod 'undo-fn' for dispatch value: null"))
Hi everyone,
Does anyone have any experience in mocking multimethods? I'm working
on a version control framework modeled after Git:
(def
^{:private true}
patches- (ref [])
(defn patches []
(seq @patches-))
(defn do-patch! [fn & args]
(dosync
(apply fn args)
(let [patc
12 matches
Mail list logo
