We've figured out a way to do groups in a simple, flexible way, that allows for probably everyone's use-cases. It requires a change to the spec and to how runners work.
Here's an implementation similar to speclj: https://www.refheap.com/15744 And this is how clojure.test would be translated: https://www.refheap.com/15752 Each test-fn may have a :group metadata key, pointing to a group-map. Group-maps must contain :description, :around-each, :around-all, and optionally its own parent :group. Then the test-results becomes a nested list rather than a flat one. If you hate using nested tests, you could just ignore it and make every test-fn have no group. The upside is that it allows (perfectly?) emulating fixtures in at least clojure.test, speclj, and midje. Another upside is it's all done statically, so you can for example choose to run a test with or without its fixtures, and you can even run a test with other fixtures if for some reason you have that need (someone said he did but I'm not sure I believe him). The downside is that now the spec talks about fixtures, which might limit innovation. But maybe not, since it's just using normal static Clojure data, which is known for very, very easily manipulated and generated. On Wed, Jun 12, 2013 at 12:13 PM, Steven Degutis <sbdegu...@gmail.com>wrote: > There's been some discussion about how nesting should work. It should > probably be part of the spec, in a flexible and non-intrusive way. Then we > would consider a flat suite of tests to be just nested suite that's only a > 1-level deep. > > The two things we want nesting for are defining fixture-like behavior > (around-each or around-all, etc), and reporting groups of tests together. > > The fixture part should almost definitely *not* be part of the spec. > That's way too limiting for innovation. But the reporting aspect probably > needs a chance to the spec. > > For fixture stuff, in speclj (rspec) parlance, you could imagine the > describe macro, which transforms a list of it-blocks into a flat list of > test-fns that are each wrapped inside any before/after/around functions > given at the same level, and recursively does this with nested describe > blocks. All this work could be done in the Definer, and no matter how deep > the describe-nesting is, the result is always still a flat list of > test-fns. This is a simple way to conform to the current spec while having > fixture-like behavior. This was my plan for the speclj port. > > But for reporting, it's trickier. The reporter needs to see the structure > somehow. This isn't easily faked with a flat list of test-results, so the > test-results would have to become potentially nested. But this raises the > question of how a flat list of test-fns produces a nested list of > test-results. > > This is the part I'm totally confused about. > > > On Sat, Jun 8, 2013 at 10:14 AM, Steven Degutis <sbdegu...@gmail.com>wrote: > >> Test2 is a new testing lib for Clojure, where the power is its >> simplicity, extensibility, and a >> SPEC<https://github.com/evanescence/test2/blob/master/SPEC.md> much >> like Ring's. >> >> Github: https://github.com/evanescence/test2 >> >> Some background: It came out of >> discussions<https://github.com/evanescence/test2/wiki/Communal-Brainstorming> >> with >> the smart folks in #clojure, who were frustrated with the inflexibility of >> existing libs, and intended this to be the spiritual successor to >> clojure.test. We wanted something that was still simple like clojure.test, >> but could be extended externally much more easily in case you wanted >> features found in clojure.test, Midje, Speclj, or Expectations, or whatever >> else. >> >> This is a pre-ANN because it's more of a call for extensions. I've >> written one last night, >> test2-autorunner<https://github.com/evanescence/test2-autorunner>, >> which took about an hour. This should give some idea of how easy it is and >> how well-designed the SPEC was by the smart folks of #clojure. There are >> some ideas at the bottom of the wiki, but of course any extensions are >> encouraged. >> >> -Steven >> >> -- >> -- >> 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. >> >> >> > > -- -- 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.
