3

I'm curious if anyone has come up with a good strategy for testing multithreaded apps.

I do alot of testing with midje, which is great for testing functions... but I'm not really sure how to test multithreaded code without it looking really hacky:

  (fact "the state is modified by a thread call"
    (Thread/sleep 100)
    (check-state-eq *state* nil)
    (Thread/sleep 100)
    (modify-state-thread-call *state* :updated-value)
    (Thread/sleep 100)
    (check-state-eq *state* :updated-value))

Sometimes, because of compilation time, my tests fail because a state was not updated in time, so then I have to sleep for longer. Ideally, I would want a way to write something like:

  (fact "the state is modified by a thread call"
    (modify-state-thread-call *state* :updated-value) 
     =leads-to=> (check-state-eq *state* :updated-value))

and move away from the sleeps. Are there strategies to do that?

CC BY-SA 3.0
Improve this question
0

2 Answers 2

Reset to default
5

If *state* in this example is one of the clojure reference types, you can add a function that is notified of every change to that object using add-watch: http://clojuredocs.org/clojure_core/clojure.core/add-watch

An approach I might suggest is to use a watch to deliver a promise when the condition is satisfied.

(let [check-promise (promise)]
  (add-watch *state* :check-for-updated-value
    (fn [rkey refr _oldval newval]
       (when (some-check newval)
          (remove-watch refr rkey)
          (deliver check-promise true))))
  (modify-state-thread-call *state* :updated-value)
  (deref check-promise 1000 false))

This will return true immediately if *state* takes on a value that satisfies some-check within 1000ms, or after 1000ms if the condition is not met, returns false.

CC BY-SA 3.0
Improve this answer
3
  • The problem I have is with having to write in the code to wait a certain length of time. Sometimes because of compilation, the times vary significantly. I like the idea of promises though I'm not too familiar with the concept
    – zcaudate
    Commented Dec 5, 2012 at 8:18
  • ooh... After looking at the code again... I understand what's going on now. It's very cool
    – zcaudate
    Commented Dec 5, 2012 at 8:37
  • Yep, it short-circuits and completes as soon as the condition is satisfied. You could easily wrap this up so that you could write (wait-for some-ref some-predicate timeout) Or you could leave the timeouts out if you're okay with the test hanging forever when you write a bug ;)
    – Crate
    Commented Dec 8, 2012 at 1:37
1

Based on Crate's response, I've created a wait function:

(defn return-val [p ms ret]
  (cond (nil? ms) (deref p)
        :else (deref p ms ret)))

(defn wait
  ([f rf] (wait f rf nil nil))
  ([f rf ms] (wait f rf ms nil))
  ([f rf ms ret]
     (let [p (promise)
           pk (hash-keyword p)
           d-fn (fn [_ rf _ _]
                  (remove-watch rf pk)
                  (deliver p rf))]
       (add-watch rf pk d-fn)
       (f rf)
       (return-val p ms ret))))

Its usage is:

(defn threaded-inc [rf]
  (future
    (Thread/sleep 100)
    (dosync (alter rf inc)))
  rf)

(def arf (ref 0))
(deref (threaded-inc arf)) ;=> 0

(dosync (ref-set arf 0))
(deref (wait threaded-inc arf)) ;=> 1
CC BY-SA 3.0
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.