On Wed, Dec 1, 2010 at 10:51, Alyssa Kwan <alyssa.c.k...@gmail.com> wrote:
> 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/ Great links - thanks Alyssa. > > > 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<clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- 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
