On 11/2/05, Jochem Maas <jochem@xxxxxxxxxxxxx> wrote: > > Manish Marathe wrote: > > Sorry for spamming but I didn't mean to reply you privately :( > > I did it myself by accident 2 minutes ago :-) > no probs. Thanks > I am sorry if I have hurted anyone's feelings here but by foolish simply > > au contraire. I don't think anyone was hurt. :) No, I was just emotionally black-mailing but in essence, I meant something which is not in best practices Is it possible to keep all the > > class files somewhere in the path where PHP can look for and I don't > > have to include in my script. > > php.ini setting include_path - its a simple concept, /^RT(?:F)?M$/. Well, I saw my php.ini earlier and I guess '.' the current directory is included in the path, so kept the file which had a class (Company) for which I wished to generate test cases in the same directory as my script ( TestGenerator.php) dir and then just tried to execute like: php TestGenerator.php Company And I didn't include Company.php in TestGenerator.php thinking that PHP will find that class since the file is in the path. but your problem is more complex than that, you are building a tool that > seems to be intend to form [part of] a php development/project environment > which means essentially you need to be able to hook in arbitrary projects > into a an installed test system which consistents of your generation tool > (and other modules). No, I am keeping it very simple for the first case. I envisage a simple interface (cmdline) to register > projects ... and a search engine thats capable of finding php code > (tokenizer?), > locating all class defs in registered projects - and keeping track of > located files. > > now imagine a generator deamon that just sits running occasionally doing > the following (triggered by e.g.: regular-timeout, cvs commit msg, soap > msg, > etc): > > scan the projects for new/changed files. > examine the found files. > (re)generate tests for each changed/new class found. > > the trick indeed to to take the monolithic process above > and parallelize it (made that word up, I think, heck C.S.Lewis did it). > > the master deamon could track which project(s) are showing most [recent!] > activity > and could for instance spawn 3 children: > > 1. SCANNER > 2. PARSER > 3. GENERATOR > > each of the above spawns a child for each [active?] project (accounting > for activity stats in order > they are spawned and more interestingly in the ammount of CPU you give > each > process? [can you even 'nice' a child process in php? note to self: rtfm] > > This is an awesome idea although I am really a noobe and really would like to start with a simple concept of generating unit test code only for php files having classes, no in-line code. But your idea definitely should shape a project developing into a practical use. Would definitely think about that!!
