I did ask attendees of last developer meeting to join this
thread.  Nobody seems to do their homework so I would like to do
my own.  Please note that anything below is my private opinion.
Never take them as canon, or any consensus.

----

I once was a SET (Software Engineer in Test) at a company of
1,000+ employee.  My role there included writing tests of someone
else's products, much like the situation of rubyspec.  Why that
company had dedicated test-automation engineers was because
writing non-garbage acceptance tests in general requires a
different skill set from writing a production code.  Of course,
people wrote their own unit tests and that's definitely a good
thing.  But they did so to _boost_ their development, not to be
conservative about their specifications.

So when it comes to ruby.  I don't think test/ruby is the ideal
solution for everyone.  I also admit it's ugly, and needs
improvements.  But at least I can say it's a wrong idea to
abondon it.  Doing so is much like to throw away unit tests and
let Selenium do everything.  Just nonsense.  Unit test is not a
spec.  They exist separately because they have different
purposes.  Merging them hurts both sides.  The (failed) past
attempts to migrate rubyspec had problems on this point, seems to
me at least.

That said.  I also have to note that tests without specs is a
poor solution.  The problems pointed by @eregon in this thread is
worth listening to.  The company I worked before solved this
problem by hiring someone to write specs.  That's not doable by
us (no such budget) but someone has to do that job somehow.  Are
we going to let the core devs do that?  Then I think we need to
motivate them.  "Spec is a good thing you should do" is a true
assertion but sounds much like a homily.  Instead show them it
benefits.  For instance, find bugs using spec and show them how
it helps their developments.

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>