> Are there any JIRA tickets open against clojure.test? That would seem > to be a good place to start. >
Good idea, that helps for gathering data about use-cases. > If someone (with a signed CA on file) wants to step up and maintain > clojure.test, even tho' it's part of core Clojure right now, I expect > a way to move forward with that could be found? Perhaps adding > test.core as a new contrib library as a copy of clojure.test and > deprecating clojure.test? > Changing clojure.test seems like the wrong way to go. Being attached to a CA makes it hard to contribute to. Being attached to Clojure makes it too slow-moving. I think everyone involved in the IRC discussion agreed that clojure.test should be deprecated it in favor of a backward-compatible, faster-moving successor. I'm certainly all for it. > But there is of course the basic question of whether a testing > framework should be part of Clojure itself (as it is now) vs a contrib > library (as test.generative is now) vs a third party library (as > Midje, Expectations, Conjecture and others are right now). > Being a third-party lib seems to me like the easiest way for it to grow and evolve properly. But maybe being a contrib-lib isn't a bad idea. I really don't know much about them and how they work. > > You're suggesting we should have started with your lib and proposed > changes. > > I don't think that's what Jay is saying. I certainly didn't interpret > his post that way. I think all he was saying - and I think all Brian > is saying about Midje - is that people aren't asking them for the kind > of extension points etc that you seem to want for test2. But that's what I meant, that he's proposing we start with his lib and add extensibility in the places we want it. So my response to that still applies. > Personally, I > think Midje is too complicated for my needs - but it's certainly very > slick - so although I've looked at it a couple of times, I've never > felt like adopting it. At World Singles, we started out with > clojure.test by default and just over a year ago converted our entire > test suite to Expectations instead because it's simpler and cleaner > and much, much easier to read than clojure.test. We since wrote a > whole bunch of tests based on clj-webdriver to replace some Selenium > (HTML-based) tests and clojure.test is a better fit there so we've > started using it again, just for that. [specifically, our webdriver > tests tend to be "do a bunch of browser stuff", "assert some > conditions with `is`", "do more browser stuff", "assert more stuff", > "click around some more", "assert some more", etc] > Think about it this way: you really just wanted to change how assertions were written. But you had to switch libs entirely. With test2, you'd just have to add a new dependency, and start writing new tests with the new assertion functions, while the old tests kept on working. Then you could rewrite old tests progressively. Until that was done, they could live side by side in your project comfortably. That's part of the goal of test2. > Is there room for another testing framework? Certainly. Could > clojure.test be improved? Definitely. Is there some standalone > infrastructure that all testing frameworks could be based on? Maybe. > Is that compelling enough that other testing framework authors would > rewrite their libraries in terms of some common infrastructure? Given > their existing libraries work just fine - and there are Emacs modes > and auto runners for them already - I'm very skeptical. > In my experience, when a tool comes out that people think is genuinely better, these things work themselves out. See how nrepl.el replaced swank. How leiningen replaced cake. How ring+compojure placed webjure and others. How Clojure replaced Ruby and CL and Python for a lot of us. When people believe in a tool, extensions for it will get written. Emacs plugins will get written or adapted. They'll do it because they really want to use it. I admit that this point won't come until it's actually got several extensions written to prove it's worth. That task probably falls on me for a little while, until the ball gets rolling. > On the other hand, there are definitely compelling tools that would > benefit from a common data structure for test run reports: displaying > results / failures to the console, feeding to JUnit HTML report > formatters (where current frameworks are pretty weak), supporting a > standard way to display red/green results in editors and IDEs (again, > existing frameworks are weak here). > Right! Being able to do these things is one of the main points! > My point is that folks either use clojure.test (and may grumble a bit > about its shortcomings - but not much based on how few JIRA tickets > exist) or they switch to a third party framework they prefer - but > across the board tooling is the weak spot (IMO). So I wouldn't spend > much time on the test machinery itself and the API that test2 exposes > since that's all very subjective - but I think the test result SPEC is > potentially very fruitful and could benefit all the frameworks... > The low number of JIRA tickets probably says more about JIRA than clojure.test. You said those 3 tickets were the only ones against clojure.test, but in the discussion there were many more complaints. Plus, people just don't have a lot of time to file tickets for all the things they wish were different. That's where informal, impromptu discussions really come in handy. That reminds me of the recent discussion panel of the Go authors (in the latest news article on golang.org). At the end, one of them says "but one thing we surprisingly never get complaints about is the lack of generics". Yeah, they probably don't. Because instead of taking the time to file an issue for it, we just used something else (I chose Clojure!). Same thing might be said about any testing library. Maybe Jay doesn't have a lot of issues or pull requests because someone looked at it, saw it missing a feature, and just silently moved on to another lib that has that feature. -- -- 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.
