pas-dev

[Pas-dev] basic unit testing....

[Kyle R . B. <mo...@vo...>]

The framework is in place, just run bin/runUnitTests and it'll do whats
advertised.

There is only 1 unit test for now: Org::Bgw::BaseTest that has 2 methods
in it, one to test construction, and 1 to test the config() method.

So the framework is in place...I now expect all of us to start writing
good unit tests for the codebase.

:)

I also expect _all_ new code to be accompanied by a unit test.  At a
minimum, the unit tests ensure at least compilation success by virtue 
that the unit test that accompanies a package/module/object will use it.

The convention that I'm setting forth is that each pakcage/file/module will
have an assocaited unit test in the same directory in the codebase (see
Base and BaseTest).  The test name will be the object name with Test as
a suffix:

  Object.pm => ObjectTest.pm

If we follow this convention, then the test runner in bin will automatcally
pick up every single unit test in the src subdirectory.

I know some people like unit tests in sepearate directoires, but I feel
that if it's in the same directory as the object its testing, the developer
will be more likely to keep it up to date.

  [user@host Bgw]$ vi Base*.pm


When we get to the point where we're starting component, system or integration
testing, we can create a testing directory structure:

  ${PAS_BASE}/testing/component
  ${PAS_BASE}/testing/system
  ${PAS_BASE}/testing/integration





Kyle


-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

Re: [Pas-dev] basic unit testing....

[Kyle R . B. <mo...@vo...>]

> Hey. I'm trying to write a unit test for this request inquisitor. I
> think I have all the third party modules I need installed. This works on
> hades, but the test keeps blowing up. I know the code is right. 
> 
> Working on desynchronized codebases is a complete pain in the ass.
> Especially since pas seems to have changed quite a bit since I started
> using it. 
> 
> I'm trying to think of ways to use this and still be able to do my own
> shit.
> 
> I could check out pas and nuke pages/ and htdocs/. I could make those 2
> dirs a link to my own repository of content and page objects.
> 
> Any ideas? 

There are no incompatible chagnes in the current version of CVS that I am 
aware of.  Why would you have to nuke your pages/ and htdocs/ directories?

Some of the code has changed, but it's all internals, none of the external
api stuff has changed, so I don't understand what the issue is.  Unless
I'm missing or forgetting something fundamental.

Why can't you just use what's in CVS for your development work?

What is the stuff that's changed since you started with Pas?


Kyle

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

Re: [Pas-dev] basic unit testing....

[Mental <me...@ne...>]

On Wed, 2002-05-22 at 15:36, Kyle R . Burton wrote:
> > Hey. I'm trying to write a unit test for this request inquisitor. I
> > think I have all the third party modules I need installed. This works on
> > hades, but the test keeps blowing up. I know the code is right. 
> > 
> > Working on desynchronized codebases is a complete pain in the ass.
> > Especially since pas seems to have changed quite a bit since I started
> > using it. 
> > 
> > I'm trying to think of ways to use this and still be able to do my own
> > shit.
> > 
> > I could check out pas and nuke pages/ and htdocs/. I could make those 2
> > dirs a link to my own repository of content and page objects.
> > 
> > Any ideas? 
> 
> There are no incompatible chagnes in the current version of CVS that I am 
> aware of.  Why would you have to nuke your pages/ and htdocs/ directories?
> 

I was being bitten by the makeGetSet stuff. I spaced on it and didnt
catch it til I tried the word-salad method of debuging.


> Some of the code has changed, but it's all internals, none of the external
> api stuff has changed, so I don't understand what the issue is.  Unless
> I'm missing or forgetting something fundamental.
> 
> Why can't you just use what's in CVS for your development work?
> 

Thats what I wanna do. You misunderstand me. I dont propose to remove MY
stuff, I plan on nuking the sample crap that comes with pas. And
actually, I dont even need to do that. I just need to setup my config
file to use a different directory for htdocs and pages. So this is a non
issue. 

What I'd been doing (and I'd like to avoid) is have everyhthing in my
own cvs repository. So in effect I was working on 2 codebases. Pas and
Pas from a few months ago + my minor stuff. Since I'm mainly doing psp
and page object work moreso than work on pas proper, I was falling
behind. 


> What is the stuff that's changed since you started with Pas?
> 

All the 3rd party modules. I had to build debs. If anyone is interested
I'll probably setup a deb repository where you can get some of hte
unbundled modules for perl. No sense cluttering up your box with a bunch
of cruft if you can avoid it. So far I've created these:
libappconfig-perl_1.52-1_all.deb
liblog-dispatch-config-perl_1.01-1_all.deb
liblog-dispatch-perl_2.00-1_all.deb

I'll put together a README.Debian file later. 
I'll have an apt source you can add to your sources.list file. I may
very well create a debian package for these modules and pas. I know
enough maintainers that getting my gpg key signed shouldn't be
difficult.... anyways.

I'm going to add a TIPS file for generic I-wish-i'd-done-this-before
stuff. 



-- 
Mental (Me...@Ne...)