I am open to suggestions for food.. do we want to do something besides pizza?
You received this message because you are subscribed to the Google Groups "London Clojurians" group.
To unsubscribe from this group and stop receiving emails from it, send an email to london-clojuri...@googlegroups.com.
To post to this group, send email to london-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/london-clojurians?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Its fine with me. I prefer pizza over sandwiches.. ;-)
event if i know sandwiches would be better for my waistline. Nevermind...
First of all: thanks to Christian and Forward for hosting the dojo.
On team 2 we tried to use TDD from the start to build an inflate/deflate library. We spent a lot of time discussing how useful the tests would be.
We looked at Clojure test.generative. We decided to avoid using it as we didn’t fully understand.
We used the red, green, refactor approach; make a test that fails (red), do enough to make it pass (green), then refactor to cover other cases.
This approach was rather slow and seemed to focus more on moving along than really thinking about our problem. There was a lot of “fake it ’til you make it” to stub a method to get green.
We also discussed how the outside-in testing approach may not be a really good fit for Clojure. We can’t be sure it’s our own fault.
We all got back together for show-and-tell, it seemed as though the other teams had a similar issue with using tests.
There was a lot of really insightful commentary on different aspects of testing with a focus on it’s application to Clojure.
We had some arguments for and against using the REPL for exploration during the test phase. Overall, it was a really helpful dojo – even though we didn’t write too much code we managed to think about the testing.
It isn't test *driven* development, but it is repl driven development
assisted by tests (RDDABT), which feels a bit like spike and
Is it good, bad or indifferent? I don't really know yet. It does let
me implement the bits that I do understand, test the bits I find
complicated or write tests for bits where I'm unsure about what the
requirement is and I want to capture my thinking.
Robert suggested that the reason I'm pursuing this is that I'm
thinking through the requirements as I'm writing the code as I don't
have a customer or product owner to tell me what things should be
doing. I think there may be some truth to this.
However, I have often found that domain experts often aren't as expert
as they sometimes appear and occasionally give answers because you've
asked them a question, rather than because it is right (if that makes
sense). Having an expert say "I don't know" is more than some are
willing to admit. Because of this I've found that when I can it is
handy to do something very quick around a corner case and then present
examples for verification, but this could be because I've mostly done
ETL and it is already a pretty remote thing for most business experts
to think about.
custard and might have nothing to do with outside in testing. I did
love the way you were always trying to reduce redundancy in the tests
and still ask myself WWSFD when testing. :-D
To me, it's similar but with a different emphasis.
To me, Top-Down implies going progressively from domain to hardware, whereas Outside-In takes you to wherever you need to go to implement the next slice of functionality.
Capt Picard? He seems to have done pretty well. When I don't think about what you might do, Steve I always ask my self WWCPD.
I think it heavily depends on your language and your tools. In
Smalltalk it's _usual_ to spend a large amount of your time in the
debugger with unit tests. It's a highly productive way to develop, in
Smalltalk at least: a good debugger that can roll back and forth on
the stack arbitrarily, fix-and-continue debugging and a dynamic
environment/language means that you can literally write your test
case, watch it fail, and implement the missing functionality entirely
in the debugger.