Re: Request to be added to PHP_LexerGenerator (and probably PHP_ParserGenerator)

On 2007 09 24 23:02, Gregory Beaver wrote:

Alan Langford wrote:

I've spent some time looking at both PHPUnit and .phpt and I have similar problems with both, which means the problem is probably with me instead... I'm trying to set things up so that I can make a change and run one or more tests in the shortest cycle possible, but both test facilities assume an installed code tree, so that PHP_LexerGenerator_Lexer is expected to be found as the installed /PHP/LexerGenerator/Lexer.php rather than CVS's PHP_LexerGenerator/LexerGenerator/Lexer.php Please tell me that there's a simple approach for this. Right now it looks like the right thing to do is to set up a parallel install of PEAR, write a build script that will push my changes and any dependencies into the parallel install, then run everything under a wrapper that points at the test environment. I'm thinking that possibly I can write an __autoload function that looks for an environment variable (PHP_PEAR_CVS_DIR) and pulls the right files in using that. Does that seem workable?

Hi Alan, Let's back up a second. The tests should be testing the environment that the user will be most likely to experience. If you're running tests out of CVS, you're in fact testing an environment that 0 (zero) users will experience. Just assume include_path is set up and require_once 'PHP/LexerGenerator.php'; When developing, you need to become a master at the samurai art of: pear up -f package.xml keep a dos box/terminal open and use <up arrow> <enter> to repeatedly upgrade when you make changes, and then you can be assured that your PEAR installation has the latest changes. Greg

Admittedly in this case it's not much of a problem, but if I was working on, say XML_RPC2, then this would have me putting test code into my production installation, which is Not Good. Actually I think the way I solved this problem was to do a local install of both PEAR and the CVS tree locally to a user on one of my Gentoo boxes, and then update and run tests from there. It's probably the vague memory of this multi-step process that was causing me to anticipate more pain than there actually is. Fortunately I have nothing in production using the Lexer, so I can get away with the simple approach. Thanks for the simplification!