Timothy Baldridge wrote:
Stuff like with-redefs and providing muck with a developer's mental
model of the source code. So instead of being able to say "well foo
calls baz here, so this should work". They have to think "well foo calls
baz unless someone re-deffs it, in which case I haven't a clue what's
going to happen, so let me go check every test that calls foo, or calls
something that calls foo to make sure it isn't overriding baz somehow".
Here I have to disagree. Technically, I think the description is wrong,
but the bit about "mental model" is more important. Midje's mocking
behavior is directly inspired by /Structure and Interpretation of
Computer Programs/' idea of "programming by wishful thinking". You write
your code assuming that whatever convenience functions you need already
exist. Then you "discover" they don't and go and write them.
Midje (and similar tools) add two things to that idea:
1. they let you run the function you're working on and see it do
something right (or wrong) before you've finished all the functions it
uses.
2. the test cases for the current function contain examples of how its
missing functions are supposed to behave.
At the end of this, your program is a lattice of functions that use each
other. You also have a collection of tests that document the assumptions
functions make about the functions they use. See
https://github.com/marick/Midje/wiki/The-idea-behind-top-down-development
It turns out to be useful when the functions so described are - and this
is fuzzy - "meaningful ideas in the domain of the program". That is,
they are "about" some part of the problem the program is supposed to
solve. When they're not - when they're just "about" the implementation
of the function that calls them, you get the sort of fragile tests I
think you're complaining about.
It shouldn't be surprising that mocks require some skill, experience,
and study to use correctly. Just like, oh, actors or logic programming
or lazy sequences, they're a simple idea that has some subtleties and
lore and non-obvious consequences.
I recommend reading /Growing Object-Oriented Software: Driven by Tests/.
The ideas are readily translated to functional languages; I actually
think they work better there.
--
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
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
