Loading ...
Sorry, an error occurred while loading the content.
 

Re: [extremeperl] Re: Testing, Audience, etc.

Expand Messages
  • Drew Taylor
    ... All your points are right on the money. I would venture to guess that most good programmers would not be against writing tests. IMHO, it s usually
    Message 1 of 20 , Feb 7, 2002
      At 11:45 PM 2/6/2002 -0700, chromatic wrote:

      ><snip> excellent points </snip>

      >I'm only sympathetic to the coders who don't yet know how and those who think
      >writing tests is difficult. (I'll even propose that, unless you're adding
      >tests to a system that has none, it *shouldn't* be difficult. If it is,
      >you're not coding for testability and you're asking for trouble.)

      All your points are right on the money. I would venture to guess that most
      "good" programmers would not be against writing tests. IMHO, it's usually
      managements edicts & timelines that forces the lack of tests. As for the
      last point, I read somewhere (perhaps in one of Steve McConnell's books)
      that a study found it takes magnitudes of more time/money to fix a bug
      after the fact that to fix it before. And if it negatively affects a
      customer, then multiply that cost by several factors for pissed off said
      customer. If only management could be made to understand this fact, getting
      tests would be much simpler. If I ever get a fulltime job again, I
      certainly will push for good tests, even if it's just unit tests.

      I was once one of those people who didn't understand how easy it is to
      write tests. Yes, it took some time to get a good test environment setup,
      but it was worth the few hous it took. And now I can easily and _quickly_
      add new tests. Modules like Test::Simple & Test::More are the key.

      >As for your Test::Harness question, use h2xs to make a skeleton Makefile.PL
      >for your project. Put your tests in the t/ subdirectory, edit the @INC paths
      >if needed, and run 'perl Makefile.PL; make; make test' and it should Just
      >Work.

      That's almost too easy... But then, this IS perl we're talking about. :-)

      [OT] As an aside, why is it that when I do Reply TO All in Eudora that the
      mailing list is on the to line twice, rather than the poster & the list?
      It's rather annoying since that is my usual behavior. Or is this considered
      bad form? I've never gotten a good answer on this question.

      Drew
      Drew Taylor JA[P|m_p|SQL]H
      http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker
      mailto:drew@... *** God bless America! ***
    • Ged Haywood
      Hi all, ... [snip] ... See attached. I once had to fly to seven or eight different countries over a period of several weeks to fix a $0.25 problem in a couple
      Message 2 of 20 , Feb 7, 2002
        Hi all,

        On Thu, 7 Feb 2002, Drew Taylor wrote:

        > At 11:45 PM 2/6/2002 -0700, chromatic wrote:
        [snip]
        > managements edicts & timelines that forces the lack of tests. As for the
        > last point, I read somewhere (perhaps in one of Steve McConnell's books)
        > that a study found it takes magnitudes of more time/money to fix a bug
        > after the fact that to fix it before. And if it negatively affects a
        > customer, then multiply that cost by several factors for pissed off said
        > customer. If only management could be made to understand this fact...

        See attached.

        I once had to fly to seven or eight different countries over a period
        of several weeks to fix a $0.25 problem in a couple of hundred $22,000
        instruments because the guy in procurement had ignored my written
        procurement specification and the guy in test had ignored my written
        test secification. The problems only started to surface when the
        instruments were used in hot places.

        It still bugs me that I didn't send a bill to their employer, who was
        my supplier and contracted to make the things to the specification.

        It's called experience.

        73,
        Ged.


        [Non-text portions of this message have been removed]
      • Rob Nagler
        ... The first step is to make sure your interface has structure. If you are testing arbitrarily constructed templates, you re going to have a rough time. If
        Message 3 of 20 , Feb 8, 2002
          > How do you do that? I've only heard of tools that allow you to create a
          > script and then playback that script. This is semiuseful, but what happens
          > if you make a change to the interface?

          The first step is to make sure your interface has structure. If you
          are testing arbitrarily constructed templates, you're going to have a
          rough time. If you build your HTML pages from widgets or
          parameterized templates, you'll have some structure to grab on to.

          > What tools/techniques have you used
          > in the past to do acceptance testing?

          The best tool is perl. We used it to test our CORBA based Web server,
          and we use it to test our application written in perl. It is not very
          hard to build an acceptance test suite using tools like LWP and
          HTMLParser.

          I am a little behind schedule. My goal is to release our internal
          infrastructure by the end of the month. It will come with a test
          suite which tests our pet shop demo (http://petshop.bivio.biz).

          > Do I have to setup a fake web server
          > environment & run the tests that way?

          I find for acceptance testing you need a test environment which is as
          close to your production environment as possible. Any of our
          developers can run the test suite on their personal Web servers.
          Every night we run the test suite against our test servers, which are
          relatively clean machines.

          > good. What I'm ultimately interested in learning is better design. Learning
          > patterns is one step, and working to see the problem from a higher level
          > view are two things I'm doing now.

          To me, there are two sides: analysis and synthesis. Patterns are
          about synthesis. XP is about analysis. I'm not a big fan of
          patterns, because they're very focused on classical object-oriented
          programming, and I try to program declaratively whenever I can. In
          addition, languages like Java, have some serious deficiencies such as
          weak ability to delegate and no class level inheritance.

          I find reading books about Lisp, functional programming, and logic
          programming expands my solution set much better than reading a book
          about design patterns.

          > OK. Why don't they just say that? :-) I know that at high levels it's
          > essential that we're all speaking the same language, but can't that
          > language be simpler?

          It is really hard to write cogent prose, which addresses a wide
          audience. They're just some concepts which are hard to explain in
          simpler language. I'm reading a book by Einstein which is incredibly
          well written but I have a really hard time understanding his
          discussions about the special theory and general theory of
          relativity. That's why I'm a programmer, I guess.

          > anyway. Besides, they're probably a little afraid of all the little bugs it
          > might turn up. ;-)
          >
          > Could this be a hidden reason some shops are wary of tests?

          I don't think so. In general, people have a hard time quantifying
          quality. If it works in the general case, it may be enough. The user
          base may be small. I really like Gerry Weinberg's comments on quality
          in his book "Quality Software Management: Vol. 1 Systems Thinking":

          The Quality Statement: Every statement about quality is a statement about some
          person(s).

          The Political Dilemma: More quality for one person may mean less
          quality for another.

          The Quality Decision: Whose opinion of quality is to count when making
          decisions?

          The Inadequate Definition of Quality: Quality is the absence of error.

          The Absence of Errors Fallacy: Though copious errors guarantees
          worthlessness, having zero errors guarantees nothing at all about the
          value of software.

          I highly recommend the book.

          Rob
        • Stas Bekman
          ... Since you are talking about testing apps against webserver, I d plug in the new Apache::Test framework which most Apache::* modules and frameworks
          Message 4 of 20 , Feb 21, 2002
            Rob Nagler wrote:

            >>What tools/techniques have you used
            >>in the past to do acceptance testing?
            >>
            >
            > The best tool is perl. We used it to test our CORBA based Web server,
            > and we use it to test our application written in perl. It is not very
            > hard to build an acceptance test suite using tools like LWP and
            > HTMLParser.
            >
            > I am a little behind schedule. My goal is to release our internal
            > infrastructure by the end of the month. It will come with a test
            > suite which tests our pet shop demo (http://petshop.bivio.biz).
            >
            >
            >>Do I have to setup a fake web server
            >>environment & run the tests that way?
            >>
            >
            > I find for acceptance testing you need a test environment which is as
            > close to your production environment as possible. Any of our
            > developers can run the test suite on their personal Web servers.
            > Every night we run the test suite against our test servers, which are
            > relatively clean machines.

            Since you are talking about testing apps against webserver, I'd plug in
            the new Apache::Test framework which most Apache::* modules' and
            frameworks' developers will find very helpful. The goal is to have every
            Apache::* module needing mod_perl or just plain apache env, use
            Apache::Test for its test. There is no more excuses for not having
            tests. And if something is missing from its functionality now it's the
            time to jump in and ask for it/add it.

            httpd-test project is using this Perl framework for testing C modules
            for Apache 1.3 and 2.0 and the server itself. And of course originally
            it was developed for mod_perl 2.0. The same test suite can work with
            httpd 1.3 and httpd 2.0. For more info see:
            http://perl.apache.org/preview/modperl-site/docs/2.0/devel/testing/testing.html

            Once we release the new modperl site (hopefully in a few weeks) this URL
            will appear as:
            http://perl.apache.org/docs/2.0/devel/testing/testing.html

            I've started mentioning XP in this doc and mention reasons for a need to
            test, but more work in needed so your help is very welcome.

            To get the framework grab the httpd-test rep from cvs or the snapshot:
            http://cvs.apache.org/snapshots/modperl-2.0/

            also see:
            http://cvs.apache.org/viewcvs.cgi/httpd-test/perl-framework/README?rev=1.8&content-type=text/vnd.viewcvs-markup

            _____________________________________________________________________
            Stas Bekman JAm_pH -- Just Another mod_perl Hacker
            http://stason.org/ mod_perl Guide http://perl.apache.org/guide
            mailto:stas@... http://ticketmaster.com http://apacheweek.com
            http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
          Your message has been successfully submitted and would be delivered to recipients shortly.