Re: Test-driven development in Clojure

2010-10-25 Thread Felix H. Dahlke
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ah, I get it. This works really well! (defn mock-page-fixture [f] (binding [load-page (fn [name] ...)] (f))) This approach feels very functional indeed, I'm going to use it. It's not really the same as my original TDD inspired design, because t

Re: Test-driven development in Clojure

2010-10-25 Thread Brian Marick
On Oct 24, 2010, at 2:03 PM, Felix H. Dahlke wrote: > I just read through this thread again and noticed that I didn't notice > you mentioning that I can stub functions within tests. I had a look at > the clojure.test documentation, but I didn't find an example of that. In Midje

Re: Test-driven development in Clojure

2010-10-24 Thread Stuart Sierra
In clojure.test, you can use the Clojure `binding` macro to provide local replacements for global functions. In Lazytest, you can use the context objects provided by lazytest.context.stub. -S On Oct 24, 3:03 pm, "Felix H. Dahlke" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi

Re: Test-driven development in Clojure

2010-10-24 Thread Felix H. Dahlke
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Stuart, I just read through this thread again and noticed that I didn't notice you mentioning that I can stub functions within tests. I had a look at the clojure.test documentation, but I didn't find an example of that. How would that apply to my

Re: Test-driven development in Clojure

2010-10-15 Thread Felix H. Dahlke
Ah, I see, thank you. Multimethods take a while getting used to I guess :) Definitely better for my problem than defprotocol though. On 14/10/10 22:13, Armando Blancas wrote: > Maybe something like this. Those calls polymorphic on the returrn > value of the anynimous function, so this is more pow

Re: Test-driven development in Clojure

2010-10-14 Thread Armando Blancas
Maybe something like this. Those calls polymorphic on the returrn value of the anynimous function, so this is more powerful than overloading. (defmulti load-page (fn [p n] (:id p))) (defmethod load-page :db [loader name] (println "db provider for page" name)) (defmethod load-page :fs [loader name]

Re: Test-driven development in Clojure

2010-10-14 Thread Felix H. Dahlke
Oh, I think I missed your suggestion of multimethods. They do in fact look pretty interesting, but I wasn't able to figure out how that would solve my problem - they look more like overloading than polymorphism to me. Would you mind posting a variant of my example that uses multimethods? On 14/10/

Re: Test-driven development in Clojure

2010-10-13 Thread Armando Blancas
One thing that OOP and FP can have in common is the use of polymorphism. With protocols and types you can implement your Java design efficiently because you'll get basically the same interfaces and classes. The thing about hiding the calls to instances of a data type is only to make the client code

Re: Test-driven development in Clojure

2010-10-13 Thread Felix H. Dahlke
I see. So instead of using interfaces and implementations of these, I would simply use closures, one for mock and one for production? That was actually my first attempt, but I didn't like it back then. Take this code for example - passing a function just to have it called feels weird: (defn load-

Re: Test-driven development in Clojure

2010-10-12 Thread Armando Blancas
> Back to my question: Am I trying to do Java in Clojure? Is there a more > Lisp-y way to do this? You can hide the types so your client code is more lispy: (defn load-page [prov] (.loadPage prov)) ;;test (def mp (make-mock-provider)) ... (load-page mp) ;;production (def prov (make-provider)) ...

Re: Test-driven development in Clojure

2010-10-12 Thread Felix H. Dahlke
The posts and Midje looks pretty interesting, but I'm not sure if I was able to follow, being new to Clojure. I'll give it another try later :) Meanwhile, I've adjourned TDD in my project and wrote some code without it to see if it makes more sense to me that way. I have to say that, although I di

Re: Test-driven development in Clojure

2010-10-12 Thread Brian Marick
On Oct 12, 2010, at 8:59 AM, Kyle R. Burton wrote: > > Does Midje integration with the usual test lifecycle for maven and Leiningen? If you type 'lein test', it'll run the Midje tests, but it doesn't hook into the reporting system (so you get 0 tests run, 0 failures reported). I want to see if

Re: Test-driven development in Clojure

2010-10-12 Thread Stuart Sierra
Datatypes that implement a single method can be more simply represented as ordinary functions, e.g. (defn real-provider ...) (defn fake-provider ...) (defn load-page [provider ...] (let [foo (provider)] ...)) That being said, you have other options: In clojure.test you can using `binding` to

Re: Test-driven development in Clojure

2010-10-12 Thread Kyle R. Burton
>> For another point of view: take a look at what Brian Marick's been >> doing with a framework called Midje to do outside-in TDD. It helps you >> mock out function dependencies and might get you where you want to go. >> It's just maturing now but I found his blog posts illuminating. > > I'll be do

Re: Test-driven development in Clojure

2010-10-11 Thread Brian Marick
On Oct 11, 2010, at 8:53 PM, John Stoneham wrote: > For another point of view: take a look at what Brian Marick's been > doing with a framework called Midje to do outside-in TDD. It helps you > mock out function dependencies and might get you where you want to go. > It's just maturing now but I fo

Re: Test-driven development in Clojure

2010-10-11 Thread John Stoneham
On Mon, Oct 11, 2010 at 6:06 PM, Felix H. Dahlke wrote: > This made me wonder if test-driven development was desirable in Clojure > at all, or even in functional programming in general. For another point of view: take a look at what Brian Marick's been doing with a framework called Midje to do ou

Test-driven development in Clojure

2010-10-11 Thread Felix H. Dahlke
Hi, I'm new to Clojure, using it for a reasonably sized project for the first time, and I'm trying to do test-driven development. While it does work well technically - clojure.test is very nice to use and feels a lot like JUnit 4's assertThat() - I'm wondering if I'm trying to program Java in Cl