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

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

Expand Messages
  • Drew Taylor
    Feb 6, 2002
    • 0 Attachment
      At 10:52 PM 2/6/2002 -0700, Rob Nagler wrote:
      >Drew Taylor writes:
      > > Specifically the acceptance tests, and how they would relate to web
      > > apps.
      >What is beautiful about the Web is that HTTP and HTML are a messaging
      >interface. You can build a complete acceptance test suite without
      >dealing with GUI scripting.
      >An acceptance test is a way of verifying end-user functions. A unit
      >test verifies programmer level functions. Both can test Web software.

      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? What tools/techniques have you used
      in the past to do acceptance testing? Do I have to setup a fake web server
      environment & run the tests that way? That wouldn't be too difficult in a
      CGI environment, and there are things like Apache::Fake now.

      > > I'm trying to become more of an "architect",
      >Before you do, read this article:
      >One of the things I'm trying to learn is to become less of an architect.

      I hadn't seen that one before, although I have read some of Joel's other
      articles. I'll read it tomorrow morning. My brief look says it will be
      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.

      > > so a lot of the "domain
      > > knowledge" stuff you & other texts mention is still a little fuzzy
      > > to me.
      >Domain knowledge is simply "the problem". What I like about XP is
      >that it is problem-oriented, not solution-oriented.

      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?

      > > I
      > > read some of the docs on bivio, and it sounded very interesting.
      > > Unfortunately more of it than I wanted was over my head. I'm very
      > intrigued
      > > about the platform you released and how to learn more about it in the
      > > future - it would be a great learning tool for me.
      >The great thing about perl is that lots of people have created lots of
      >code. We put out bOP, because it has no intrinsic value as a
      >product. There are just too many good toolkits out there. I consider
      >this a testament to perl more than anything else. You can create
      >incredibly solid software very quickly.

      This ability to quickly create a great product is one of the things that
      really attracted me once I got serious about perl. I've seen several
      frameworks that have interested me, including OpenInteract, OpenFrame, and
      Mason. One day I hope I have the time to put some effort into learning each
      better. I can just imagine all the tidbits of knowledge waiting to be
      gleaned from each one.

      > > It sounds like the tests I wrote last night would be unit tests as they
      > > test object instantiation & the APIs.
      >Yes, it sounds like you wrote unit tests. They are incredibly
      >important tools. We're slowly creating unit tests for our code. It's
      >tough to do, but we regret it every time we make changes and there is
      >no test to validate that we haven't broken anything.

      Yep, they were definitely unit tests. And as I mentioned before, I'm very
      grateful I've written the ones I have because they did exactly what they're
      supposed to do. Tell me when bugs appear and when they've been fixed. Once
      I've gotten more tests done, I need to look into Test::Harness so I can run
      them all at one swoop.

      To illuistrate your last point, I have an example. At a previous employer,
      we had a large codebase of perl modules (I bet it's probably doubled by
      now) but no tests. I'm still close friends w/ the lead QA person and she
      often just tests what she can and blindly hopes everything else still
      works. It's just not possible to test every facet of the code for every
      release (which is every 1-2 months). I really doubt that a comprehensive
      test suite will ever be written, even though I have no doubt that it would
      be an extremely important tool. The CTO's not convinced of the need, and I
      don't think they would have/put the time to write a comprehensive suite
      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?

      Drew Taylor JA[P|m_p|SQL]H
      http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker
      mailto:drew@... *** God bless America! ***
    • Show all 20 messages in this topic