Re: On Testing
Here a example where midje could provide more info.
I have this function :
(defn pr134 [element a-seq]
(and (contains? a-seq element) (nil? element))
)
and I have this test-function :
(ns exercises.core-test
(:use midje.sweet)
(:use [exercises.core]))
(facts "about `pr134`"
(fact "it normally return true if the key exist and the value is nil"
(pr134 :a {:a nil :b 2}) => true
(pr134 :b {:a nil :b 2}) => false
))
Then I see this output :
FAIL
"about `pr134` - it normally return true if the key exist and the value is
nil" at (core_test.clj:7)
Expected: true
Actual: false
FAILURE: 1 check failed. (But 1 succeeded.)
So I do not know if the first part contains? or the second one nil? is
wrong.
I know it mentioned before if you look at the way groovy does , you get
more info like this made up example.
(and (contains? a-seq element) (nil? element)) schould be true
| |
|
true
false |
|
|
false
true
Roelof
Op zondag 2 november 2014 03:04:38 UTC+1 schreef Devin Walters (devn):
>
> http://jakemccrary.com/blog/2014/06/22/comparing-clojure-testing-libraries-output/
>
> has some good examples. I'm currently using humane-test-output. It's worked
> nicely for me.
>
> '(Devin Walters)
>
> On Nov 1, 2014, at 7:00 PM, Alex Miller > wrote:
>
> Additionally, I think it would be helpful to enumerate example (failing)
> tests and their output by current clojure.test.
>
>
> On Saturday, November 1, 2014 1:58:32 PM UTC-5, Alex Miller wrote:
>>
>> It would be great if someone could enumerate more explicitly what
>> "better" test output means. What are the specific problems in the current
>> test output reporting?
>>
>> Similar problem list for test runner might be useful.
>>
>> Discussion here is fine but ultimately needs to land on a design wiki
>> page.
>>
>> I am happy to do what I can to move this through a process toward
>> inclusion in a release.
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
--
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.
Re: On Testing
http://jakemccrary.com/blog/2014/06/22/comparing-clojure-testing-libraries-output/ has some good examples. I'm currently using humane-test-output. It's worked nicely for me. '(Devin Walters) > On Nov 1, 2014, at 7:00 PM, Alex Miller wrote: > > Additionally, I think it would be helpful to enumerate example (failing) > tests and their output by current clojure.test. > > >> On Saturday, November 1, 2014 1:58:32 PM UTC-5, Alex Miller wrote: >> It would be great if someone could enumerate more explicitly what "better" >> test output means. What are the specific problems in the current test output >> reporting? >> Similar problem list for test runner might be useful. >> >> Discussion here is fine but ultimately needs to land on a design wiki page. >> >> I am happy to do what I can to move this through a process toward inclusion >> in a release. >> > > -- > 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. -- 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.
Re: On Testing
Additionally, I think it would be helpful to enumerate example (failing) tests and their output by current clojure.test. On Saturday, November 1, 2014 1:58:32 PM UTC-5, Alex Miller wrote: > > It would be great if someone could enumerate more explicitly what "better" > test output means. What are the specific problems in the current test > output reporting? > > Similar problem list for test runner might be useful. > > Discussion here is fine but ultimately needs to land on a design wiki page. > > I am happy to do what I can to move this through a process toward > inclusion in a release. > > -- 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.
Re: On Testing
On Nov 1, 2014, at 1:58 PM, Alex Miller wrote: > It would be great if someone could enumerate more explicitly what "better" > test output means. What are the specific problems in the current test output > reporting? If there's any sort of consensus about test reporting, specifically how differing collections should be printed, I'll implement/include that in Midje. Note: speclj and Midje are the frameworks that most support mocking (or, as I like to think of mocking: prerequisites and axioms). That adds some complexity to test output. For example, a single evaluate-function-and-check-the-result operation can fail for more than one reason at once. Latest book: /Functional Programming for the Object-Oriented Programmer/ https://leanpub.com/fp-oo -- 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.
Re: On Testing
I can say for certain that at a minimum better indentation of data structures to the console would be a must, a vector with 4+ hash maps in it are currently unreadable and I have to copy to an editor to indent and analyze. Beyond that, I can imagine the need for a structural diff that tells me in a human readable form how things are different. Different types (plain sequence vs hash map), different positions or keys in structures, etc. On Sat, Nov 1, 2014 at 12:58 PM, Alex Miller wrote: > It would be great if someone could enumerate more explicitly what "better" > test output means. What are the specific problems in the current test output > reporting? > Similar problem list for test runner might be useful. > Discussion here is fine but ultimately needs to land on a design wiki page. > I am happy to do what I can to move this through a process toward inclusion > in a release. > -- > 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. -- 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.
Re: On Testing
It would be great if someone could enumerate more explicitly what "better" test output means. What are the specific problems in the current test output reporting? Similar problem list for test runner might be useful. Discussion here is fine but ultimately needs to land on a design wiki page. I am happy to do what I can to move this through a process toward inclusion in a release. -- 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.
Re: On Testing
That's an excellent idea, currently at least test.check hacks on top of clojure.test by using macros that emit clojure.test tests. Beyond that it seems that the #1 wish is better output. I don't think that ought to be very hard for us to pull off as a community. On Fri, Oct 31, 2014 at 6:56 PM, Andrew Rosa wrote: > +1 to something like humane-test-output being part of core library. > There is value for the community to have some foundation library share > across our test frameworks? Something like `test.runners`, to encapsulate > error reporting and organization? Bit crazy, I know, but the idea come > after seeing Haskell's https://github.com/feuerbach/tasty. OK, I don't do > Haskell, but I kind of like the way of composing a single integrated suite > of different flavors of test. > Andrew > On Friday, October 31, 2014 10:41:09 PM UTC-2, John Louis Del Rosario wrote: >> >> Would be great if humane-test-output was part of clojure.test. Would make >> it easier for beginners to find it. >> >> On Friday, October 31, 2014 11:19:11 PM UTC+8, Eli Naeher wrote: >>> >>> On Fri, Oct 31, 2014 at 9:52 AM, Ashton Kemerling >>> wrote: >>> >>> It's my opinion that these two libraries are largely complete aside from some human interface improvements (quality of output for example), but clearly not everyone agrees with me. >>> >>> Hi Ashton, >>> >>> Check out https://github.com/pjstadig/humane-test-output if you haven't >>> already seen it, it's a nice improvement over the default output--in >>> particular seeing the specific diffs between expected and actual values is >>> really useful when you are dealing with collections. >>> >>> -Eli >>> >> > -- > 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. -- 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.
Re: On Testing
+1 to something like humane-test-output being part of core library. There is value for the community to have some foundation library share across our test frameworks? Something like `test.runners`, to encapsulate error reporting and organization? Bit crazy, I know, but the idea come after seeing Haskell's https://github.com/feuerbach/tasty. OK, I don't do Haskell, but I kind of like the way of composing a single integrated suite of different flavors of test. Andrew On Friday, October 31, 2014 10:41:09 PM UTC-2, John Louis Del Rosario wrote: > > Would be great if humane-test-output was part of clojure.test. Would make > it easier for beginners to find it. > > On Friday, October 31, 2014 11:19:11 PM UTC+8, Eli Naeher wrote: >> >> On Fri, Oct 31, 2014 at 9:52 AM, Ashton Kemerling >> wrote: >> >> >>> It's my opinion that these two libraries are largely complete aside from >>> some human interface improvements (quality of output for example), but >>> clearly not everyone agrees with me. >>> >> >> Hi Ashton, >> >> Check out https://github.com/pjstadig/humane-test-output if you haven't >> already seen it, it's a nice improvement over the default output--in >> particular seeing the specific diffs between expected and actual values is >> really useful when you are dealing with collections. >> >> -Eli >> > -- 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.
Re: On Testing
Would be great if humane-test-output was part of clojure.test. Would make it easier for beginners to find it. On Friday, October 31, 2014 11:19:11 PM UTC+8, Eli Naeher wrote: > > On Fri, Oct 31, 2014 at 9:52 AM, Ashton Kemerling > wrote: > > >> It's my opinion that these two libraries are largely complete aside from >> some human interface improvements (quality of output for example), but >> clearly not everyone agrees with me. >> > > Hi Ashton, > > Check out https://github.com/pjstadig/humane-test-output if you haven't > already seen it, it's a nice improvement over the default output--in > particular seeing the specific diffs between expected and actual values is > really useful when you are dealing with collections. > > -Eli > -- 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.
Re: On Testing
I totally agree about pr-str in test.check. Quite often I want to copy and paste the failure into a repl and play around, but need to re-add missing quotation marks or quote lists. > On 31 Oct 2014, at 22:05, Jessica Kerr wrote: > > My top wish it more readable output from test.check when running within > clojure.test > > In particular, I want to know the value of each generated parameter at the > first failure, and at the simplest failure. Currently that prints as part of > a map, but if empty-string is generated, that does not show. (Forking and) > printing with pr-str improves it, but I'd like to do a lot more with that. > -- > 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. -- 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.
Re: On Testing
My top wish it more readable output from test.check when running within clojure.test In particular, I want to know the value of each generated parameter at the first failure, and at the simplest failure. Currently that prints as part of a map, but if empty-string is generated, that does not show. (Forking and) printing with pr-str improves it, but I'd like to do a lot more with that. -- 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.
Re: On Testing
On Fri, Oct 31, 2014 at 9:52 AM, Ashton Kemerling wrote: > It's my opinion that these two libraries are largely complete aside from > some human interface improvements (quality of output for example), but > clearly not everyone agrees with me. > Hi Ashton, Check out https://github.com/pjstadig/humane-test-output if you haven't already seen it, it's a nice improvement over the default output--in particular seeing the specific diffs between expected and actual values is really useful when you are dealing with collections. -Eli -- 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.
Re: On Testing
"I tweeted recently that I thought that Clojure is super testable, and I was genuinely surprised about the number of people who disagreed with me." My 2c. Without explicitly citing those complaints, it will be difficult to conduct a meaningful debate. 2014-10-31 14:52 GMT+00:00 Ashton Kemerling : > I tweeted recently that I thought that Clojure is super testable, and I > was genuinely surprised about the number of people who disagreed with me. > > There's been a lively discussion about what the best testing frameworks in > clojure currently are, and what the built in solutions (clojure.test and > test.check) are lacking. While a lot of people recommend midje or > expectations, I generally prefer the built in options (no offense to > contributors of either of those libraries) and usually recommend people > stick with clojure.test for its lack of magic. > > It's my opinion that these two libraries are largely complete aside from > some human interface improvements (quality of output for example), but > clearly not everyone agrees with me. > > So let's talk about what we could add to make the clojure testing > experience superior compared to other languages. > > -- > 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. > -- László Török Checkout justonemorepoint.com - Know your true value -- 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.
Re: On Testing
I don't want to speak for others, I notified everyone involved on Twitter that I made this thread so they can voice their own complaints. On Fri, Oct 31, 2014 at 9:02 AM, László Török wrote: > "I tweeted recently that I thought that Clojure is super testable, and I > was genuinely surprised about the number of people who disagreed with me." > My 2c. > Without explicitly citing those complaints, it will be difficult to conduct > a meaningful debate. > 2014-10-31 14:52 GMT+00:00 Ashton Kemerling : >> I tweeted recently that I thought that Clojure is super testable, and I >> was genuinely surprised about the number of people who disagreed with me. >> >> There's been a lively discussion about what the best testing frameworks in >> clojure currently are, and what the built in solutions (clojure.test and >> test.check) are lacking. While a lot of people recommend midje or >> expectations, I generally prefer the built in options (no offense to >> contributors of either of those libraries) and usually recommend people >> stick with clojure.test for its lack of magic. >> >> It's my opinion that these two libraries are largely complete aside from >> some human interface improvements (quality of output for example), but >> clearly not everyone agrees with me. >> >> So let's talk about what we could add to make the clojure testing >> experience superior compared to other languages. >> >> -- >> 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. >> > -- > László Török > Checkout justonemorepoint.com - Know your true value > -- > 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. -- 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.
On Testing
I tweeted recently that I thought that Clojure is super testable, and I was genuinely surprised about the number of people who disagreed with me. There's been a lively discussion about what the best testing frameworks in clojure currently are, and what the built in solutions (clojure.test and test.check) are lacking. While a lot of people recommend midje or expectations, I generally prefer the built in options (no offense to contributors of either of those libraries) and usually recommend people stick with clojure.test for its lack of magic. It's my opinion that these two libraries are largely complete aside from some human interface improvements (quality of output for example), but clearly not everyone agrees with me. So let's talk about what we could add to make the clojure testing experience superior compared to other languages. -- 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.
Re: Opinion on testing strategies?
The feedback that comes immediately to mind: * it sounds like property #3 complects black box vs white box and specification vs implementation concerns * it sounds like the feature functions potentially combine the state and calculation layers in ways that should be internally reused, but also are externally exposed through a public API. These two needs should probably be decoupled * it should be an implementation detail of X that X calls Y. This is just a convenience. From a blackbox perspective, all that X's callers care about is that X's contract is satisfied. They don't know and shouldn't care that this is done by calling Y. Satisfying this behavior could be done by calling Y, or calling a Y', or some other internal magic. The knowledge that it currently is done by calling Y is irrelevant to the perspective of satisfying a contract and shouldn't be reflected in testing that contract * that said, it sounds like Y, contractually, is actually a subset of X, a shortcut, to be used when the extra conditions that require X don't exist. So testing Y should be able to be done through X's tests. Some suggestions: * it sounds like there should be another internal layer for reusable combinations of state and calculation functionality, and Y's implementation should get moved in there. Then Y, as a public API, is mostly just a wrapper of that fn. X, as a public API, should also call that library fn, not Y. * that library fn can be tested in a whitebox fashion, with-redefs to mock out the underlying internal functions so the unique behaviors are exercised * for blackbox API testing, since it sounds like X and Y have specification/contractual details in common, and Y may satisfy callers of X who have simpler conditions- the 25 tests for X are needed, but the 5 of those that apply when the extra X requirements are null can simply be repurposed against the Y endpoint- as long as that's what the contracts say. Hope that helps/makes sense, apologies if it misinterprets the question. On Sat, Apr 6, 2013 at 8:42 PM, Steven Degutis wrote: > 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'
Re: Opinion on testing strategies?
On Sat, Apr 6, 2013 at 5:42 PM, Steven Degutis wrote: > What do you think? What approach would you take in this situation? I guess I'd turn it around and ask what new problems you think functional programming introduces for testing - and why do you think that? In general, I've found that writing tests for functional code is substantially easier than for traditional procedural / OOP code, so I suspect there's something wrong in your thought process, but based on how you've presented it, I'm not sure where to start poking holes first... How would you test this stuff traditionally? How would you deal with these problems traditionally? And if you think they're specific to FP, why? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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.
Re: Opinion on testing strategies?
Forgive me if I completely misunderstood your question. Replies inline. 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 would be similar to mocking, correct? If so, what'd be wrong with it? > 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. > > You could have pre-conditions in your fns to check for this. Considering that this scenario is bad in general, not just in testing, this might be the thing to do anyway. > 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. > > It's a trade-off. How much testing is enough testing? > 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. > > I'd probably say that if you've tested Y and you're happy with those tests then you can just mock it in X's calls. > 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. > > This doesn't strike me like a good idea :) U -- -- 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.
Opinion on testing strategies?
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.
Re: [ANN] modern-cljs - tutorial 9 on testing (part 1)
ops. thanks mimmo On Dec 2, 2012, at 10:15 PM, Michael Klishin wrote: > 2012/12/3 Mimmo Cosenza > I just published the 9th tutorial of the series modern-cljs. > > It talks about testing. It uses the CLJS proposed patch as a true sample > case to work on. > HIH > > The link: > https://github.com/magomimmo/modern-cljs/blob/master/doc/tutorial-09.md > > Thank you! > -- > MK > > http://github.com/michaelklishin > http://twitter.com/michaelklishin > > > -- > 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 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
Re: [ANN] modern-cljs - tutorial 9 on testing (part 1)
2012/12/3 Mimmo Cosenza > I just published the 9th tutorial of the series modern-cljs. > > It talks about testing. It uses the CLJS proposed patch as a true sample > case to work on. > HIH > The link: https://github.com/magomimmo/modern-cljs/blob/master/doc/tutorial-09.md Thank you! -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- 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
[ANN] modern-cljs - tutorial 9 on testing (part 1)
Hi, I just published the 9th tutorial of the series modern-cljs. It talks about testing. It uses the CLJS proposed patch as a true sample case to work on. HIH My best Mimmo -- 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
