Hi Mike, "TDD as if you meant it" - http://gojko.net/2009/02/27/thought-provoking-tdd-exercise-at-the-software-craftsmanship-conference/
What you want is mocking and stubbing (these are different things!). http://s-expressions.com/2010/01/24/conjure-simple-mocking-and-stubbing-for-clojure-unit-tests/ Remember that unit testing is NOT integration testing... Thanks, Alyssa On Dec 1, 8:29 am, Laurent PETIT <laurent.pe...@gmail.com> wrote: > Hi, > > 2010/12/1 Michael Ossareh <ossa...@gmail.com> > > > Hi All, > > > In the course of putting together my latest piece of work I decided to > > really embrace TDD. This is run of the mill for me in Java: > > > - create some object that models your flow > > - create some object which contains your storage logic > > - create tests > > - dependency inject the correct storage logic depending on which scenario > > you're running in (prod / test / etc). > > Hum, this process does not seem to be eligible to be named "TDD". In TDD, > the tests are written first and "shape" the interface of your solution. Here > what to do is more "traditional": you write your domain objects, your logic, > and you add tests. > Not a critic of the methodology (I'm not advocating any methodology over > another here, to be clear), but rather a thought on how things are named. > > Some more thoughts (not sure they will help, but who knows ?) : > > > I've not been able to think about how to correctly achieve this same > > functionality in clojure. > > > So far everything is pretty much pure functions, the storage functions > > being the only place where data is changed. Currently the storage is > > implemented with atomic maps. The production storage will be in Riak. > > Hmm, if by "storage functions being the only place where data is changed" > you mean that in storage functions you do 2 things: change the value and > store them, then IMHO you could split them in 2. > > > > > > > I'm getting ready to build the Riak backend and now I'm faced with how to > > choose the correct backing implementation. I've a namespace, > > rah.test-storage, which implements the in-memory storage and I anticipate > > putting riak storage in rah.riak-storage - however I'm not sure what the > > best way to select the correct implementation at runtime or test time is. > > > One solution I've come up with is to use defprotocol to define the > > functions for the storage layer (as you would an interface in java) and then > > have a defrecord for each implementation. Assume these to be in the > > namespace rah.storage, which would also house the functions which call the > > correct defrecord functions based on a property given at start time. > > > This solution, however, feels like me trying to write Java in clojure - and > > I'm wondering how the lispers of the world would solve this same issue. > > > Another solution would be to write the same set of functions in the > > rah.storage namespace which then look at the same property and then decide > > whether to call rah.riak-storage/store-user! or > > rah.test-storage/store-user!. > > The solution, as every solution, will have to be a trade-of. > Here one "axis" for the tradeoff can be seen as "how powerful you want your > backend connectivity to be (singleton backend per app ? possibly several > different backends at the same time ? pluggable backends during runtime ?) > versus the ease of writing the app (the more probability you want power, the > more probability there will be to have a "backend" object to be passed > around : no backend object in case of a singleton backend for the app, > several singleton backend objects). Note that if you know that each > singleton backend will be of a "different kind" than the others, then simply > a keyword for representing each backend may be sufficient. > > From what I can infer from what you described, if you would write the > application without caring about programmatic testing, you would be fine by > just having top level functions, and probably a top level configuration map > with key/values for backend location, credentials, etc. > > If so, then it may be sufficient to leverage the possibility, in your > testing "framework" (clojure.test ? anything else ...) to redefine the > functions of the backend before the tests run. I'm pretty sure there are > already such features allowing to temporarily "redef" (and "restore" at the > end) the root value of global vars. > > HTH, > > -- > Laurent- Hide quoted text - > > - Show quoted text - -- 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 your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en