Thanks for the comments, Luke, glad we're thinking along the same lines! -Stuart Sierra
On Jan 19, 1:24 pm, Luke Amdor <luke.am...@gmail.com> wrote: > Thanks Stuart for the with-test macro. It will make my life much > easier. I have been putting my tests in the :test metadata and running > them with (run-tests). The with-tests macro will make it much more > readable. I was also having problems with old test metadata hanging > around. > > I am all in favor of putting the tests right next to the function > being tested. The anti-"side effect" nature of Clojure promotes this > in fact. If I can have a test suite ran upon loading with no required > assistance from the caller, that would be great. > > I also think that if your test needs a description of what it's doing, > then that's a smell. It's an excuse for easily readable code and I > think we can all agree that we should try to make our code as easily > readable as possible. > > Luke > > On Jan 18, 3:03 pm, James Reeves <weavejes...@googlemail.com> wrote: > > > On Jan 18, 4:24 pm, Stuart Sierra <the.stuart.sie...@gmail.com> wrote: > > > > After thinking a while about the discussion about test-is <http:// > > > groups.google.com/group/clojure/browse_thread/thread/59e9cebbe67cab3f/ > > > 508f1e8de753455c>, here's a short article with my current thoughts: > > > >http://stuartsierra.com/2009/01/18/tests-are-code > > > > Comments welcome here or on the blog. > > > I've written an RSpec-like testing framework in Clojure, so I have a > > few opinions on this. > > > 1. I don't like the idea of putting tests next to the functions > > they're testing. There's an argument that says tests make good > > documentation, but I'm of the opinion that tests are too repetitive to > > be effective in that capacity. A good piece of documentation will > > provide several common examples; a thorough test will go through > > dozens of edge-conditions. So if tests aren't documentation, putting > > them next to the functions they test just clutters up the source code > > with unnecessary information. > > > 2. Test should come with a description of what scenario they are > > testing, so I favour the RSpec approach of using short descriptive > > strings to identify tests, rather than symbols. > > > 3. The biggest problem I've had with tests is generating test data. I > > like the Quickcheck approach of generating lists of random values > > (because it's easy for me), but when trying to use that approach in my > > Fact testing framework I've found that really only works with a > > minority of problems. I haven't figured out a good solution for easily > > generating test data, but I think it's one of the most important > > problems for a unit testing framework to overcome. > > > 4. I lean toward the idea that a test should contain a single > > predicate that's tested with numerous inputs. But again, I haven't > > figured out a way of doing this that works well in all situations :) > > > - James --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
