Re: [Chicken-users] Re: Integrating unit tests into source code

[Peter Bex]

On Thu, Dec 14, 2006 at 03:41:44PM -0800, Brandon J. Van Every wrote:
> 
> I know and understand why to use tests.  I'm not opposed to tests,
> but I am opposed to lumping the tests in with the main code.
> I'd much rather just keep the code clean and put the tests in
> another file.
>   
>    Well,  I  question  why we have files.  We have historical reasons for
>    it; all of our text editors are built in terms of them.  But a program
>    is really just one big database of stuff, and it might make more sense
>    to  have  it  all  uniformly  accessed and searched, rather than being
>    cobbled across a filesystem.
>    Thus  I  am saying, "why should it appear together" vs. "why should it
>    appear  apart,"  is  pretty arbitrary and historical.  If one regarded
>    the program as a database, then either is just a view of the database.

When the time comes that all tools support this kind of "I choose what
I want to see" stuff, you won't need files and there's no problem with
lumping everything together because you select your own preferred view
for the particular task you're working on.  Unfortunately (?), that time
isn't here yet and we have to make do with imperfect plaintext-editors
(though paredit.el really helps).

>    Only  if those specifications are terse, legible, and universal enough
>    to  describe  nearly any class of problem that needs specification.  I
>    have  my doubts, but I haven't tried this paradigm.  I suspect my eyes
>    will glaze over, and that deciphering contracts isn't much better than
>    deciphering simple tests.

What I read between the lines is that you're opposed to this idea because
you don't have any experience with it.  I bet once you've seen a few
programs that work like this, you will gradually learn how to read them
and that will mean a productivity increase.
When you first came into contact with a recursive Scheme program, didn't
you think it was very difficult to read?  I did, because I had only
experience with imperative programming.  Just because it's a new paradigm
you're not familiar with doesn't mean it's bad.

I'm sure specifications in the form of contracts, if done properly, are
a lot more terse than tests.  Which is exactly why I'm so fiercly opposed
to inline tests.  As an example: A big project I'm working on at work has
a core library that has to be tested well.  The library is only 400 lines
of Ruby code (it builds on existing classes), but it has ~1400 tests.
That is an awfully big test:code ratio.  You really don't want to have
these tests inlined!

>   Tests
> don't say shit.  They're a very low-level and nonsemantic way of
> groping around to ensure your corner cases are covered.
> 
>    Depends  on  the  test.   I think the comments are what help.  I don't
>    care  what  kind of code someone writes, it's gonna make my eyes glaze
>    over.

Again, this is personal.  In my opinion, code is the only thing that
really counts.  Comments are often neglected with the heat of a deadline
on your heels, or don't touch upon every aspect. (what exceptions does
it raise?  What should happen if I supply some particularly strange
combination of arguments?)  The code is what is going to happen in the
machine once the thing is running.  Tests may miss significant situations
people just didn't think of at the time.  Same goes for contracts, by
the way.  If you do not want to read code, you shouldn't be in the
programming business.

>    Declarative   styles  are  not  panacea.   Some  problems  are  better
>    specified  imperatively.   Sometimes  you  really want to know that "A
>    happens, then B happens, then C happens" and it's easier to debug.

That's a matter of personal preference.  I am sure a lot of Schemers
will disagree with you here.

>    The  latter.   Because  I'm  probably  implementing  a  bit  twiddling
>    optimization algorithm, and I need to know exactly what's happening as
>    the   code  converts  to  machine  instructions.   When  you  state  a
>    preference  for declarative interfaces, you are implicitly stating you
>    don't  want  to be bothered with the implementation details.  That you
>    prefer  abstract  problems.   Now  that  may have its place in various
>    problem domains, but not typically in mine.

If your domain is the odd one out, should Chicken really give second-class
treatment to all those other ones?  Of course, from your perspective it
should right now, but what if you need to write some entirely different
type of program?  Wouldn't you like to do it the best way possible, and
in Chicken?

>    Bigger is fine.

I really dislike Java and C# where you often end up with huge amounts
of boilerplate code.  Bigger is *not* better, that's one of the reasons
we have macros.

I suppose we just have to agree to disagree on this issue.  Maybe a user
poll about what approach to take is in order?

Regards,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

pgpbHG_ZrIRre.pgp
Description: PGP signature