Disclaimer: this isn't strictly about Clojure, more about semi-functional programming techniques, which Clojure excels at. (Plus I'm using Clojure for it.)
Lately I've been experimenting with ditching the conventional MVC approach to writing a web app. Now controllers are just dead-simple functions that translate HTTP to/from our feature functions (or business logic functions). Each of these feature functions do some or all of these things: 1) change some persisted state 2) return result of calculations on persisted and/or given data 3) call another feature function Functions often build upon other functions. This leads to a sort of pyramid, where the entry-point of the feature (usually called by a controller) is the tip, and the most primitive functions are at the bottom. Testing each individual function for behaviors #1 and #2 is straightforward. But I'm running into a problem testing behavior #3. One way is to use `with-redefs`. This technique would be used at every level along the pyramid (except the bottom level which doesn't call anything else). This feels very fragile. For one thing, if any of the function signatures change, any tests that reference that function have to change too, or they'll become false positives, no longer representing the real world, just the imaginary world that was setup in the test. Another way is to test state changes and return values at every level in the pyramid. This represents the real world more, because if any feature function changes, all the tests above it will fail. But there's two problems with this. First, there's going to be a lot of redundancy in test data in the vertical slice of the pyramid for a single feature. I'm on the fence of whether that's really a problem. Secondly and more importantly, each feature function's tests will also have to cover all the behaviors of the functions it calls, besides testing its own behaviors. For example, X calls Y. X has 5 behaviors and Y has 5 behaviors. So Y will have 5 tests, but X will have 25. This is because, from a high level, we only care about the feature as a whole (a.k.a. X) and Y is only an auxiliary function to assist X. We, the stakeholders of feature X, don't know or care that Y exists. So Y's tests are irrelevant to us, who just want to know that X does its job. So we want to see all of X and Y's behaviors tested, without knowing about Y, to give us confidence that X does all 25 things. But we still need to be responsible and test Y, especially because X delegates half his work to Y in the name of healthy abstraction. A third way is to sprinkle small amounts of Y's behavior into some or all of X's tests. This relies heavily on probability, suggesting that X is probably using Y because he shares at least one of Y's behaviors. If it's true, then we know that X shares all of Y's behaviors. It becomes a sort of "linked list" of features, with the sprinkled-in behavior of Y acting like a "next" pointer. The downside is that there's a pretty fair chance that I didn't really call Y, but I just copied/pasted some of his behavior. Sure, not immediately after writing the test. But 6 months in the future, when I've forgotten why I wrote the test this way, and I see that X is calling Y when the test says he just wants to use a fifth of Y's behavior, I'll think it's overkill and rip out the call to Y, replacing it with just whatever X's test specifies. Then it just became another deadly false positive. These are all the testing techniques I can think of for #3. Maybe there's more that I just don't know about. What do you think? What approach would you take in this situation? -- -- 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/groups/opt_out.
