php-windows Digest 2 Feb 2010 06:37:43 -0000 Issue 3753
Topics (messages 29839 through 29844):
Re: A way available to test PHP CGI builds.
29839 by: Pierre Joye
29840 by: Venkat Raman Don
29841 by: Pierre Joye
29842 by: Venkat Raman Don
29843 by: Pierre Joye
29844 by: Venkat Raman Don
Administrivia:
To subscribe to the digest, e-mail:
php-windows-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-windows-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-wind...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
hi,
On Mon, Feb 1, 2010 at 7:26 PM, Venkat Raman Don
<don.ra...@microsoft.com> wrote:
> Hi All,
>
> I would like to announce that with the commit
> http://svn.php.net/viewvc?view=revision&revision=294232, we can have a way to
> test PHP-CGI.exe on Windows. More details around this can be found at
> http://blogs.iis.net/donraman/archive/2010/02/01/wincache-test-code-committed-to-pecl-paves-a-way-to-test-php-cgi.aspx.
>
> It does need some more thinking and work. Please let me know in case you have
> some ideas and willing to contribute.
It was already possible to test php-cgi.exe just fine before by
setting the required ENVIRONMENT variables. That's what we use for the
run-tests cmd in our tree (all platforms), it supports post/upload/get
as well.
Am I mistaken or what this application does is to remote control IE to
load a given URL? This URL being the test we like to test, from the
document root? If yes, that's something relatively easy to do using
PHP directly (php supports http natively btw). It is also easy to run
the test using a given users using runas, that does not match 100% the
configuration of IIS+FCGI, but from a PHP only point of view, it
covers all cases.
Btw, take a look at the server scripts in the php src tree.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--- End Message ---
--- Begin Message ---
Hi Pierre,
Thanks for the comments.
I am aware of the fact that we can test php-cgi.exe in various scenarios which
is very close to real world. But my code gives the ability to test php-cgi.exe
exactly like real world. Most of the people use PHP to host some application.
It can be home grown application, a community application or a variance of a
community application. This is exactly what the code simulates. And one more
clarification it is not dependent on any server or how one has configured to
run PHP. It can be IIS/APACHE (or any other server for that matter) and is also
not dependent on how you server is configured. It can be mod_php/FastCGI/ISAPI
etc. So far as your code can run in the browser, the driver has the ability to
test it. The only flaw is that it runs primarily on WINDOWS as it takes a hard
dependency on Internet Explorer being the browser. I believe if we found this
useful the hard dependency can be removed.
Thanks,
Don.
-----Original Message-----
From: Pierre Joye [mailto:pierre....@gmail.com]
Sent: Monday, February 01, 2010 10:42 AM
To: Venkat Raman Don
Cc: php-wind...@lists.php.net
Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
hi,
On Mon, Feb 1, 2010 at 7:26 PM, Venkat Raman Don <don.ra...@microsoft.com>
wrote:
> Hi All,
>
> I would like to announce that with the commit
> http://svn.php.net/viewvc?view=revision&revision=294232, we can have a way to
> test PHP-CGI.exe on Windows. More details around this can be found at
> http://blogs.iis.net/donraman/archive/2010/02/01/wincache-test-code-committed-to-pecl-paves-a-way-to-test-php-cgi.aspx.
>
> It does need some more thinking and work. Please let me know in case you have
> some ideas and willing to contribute.
It was already possible to test php-cgi.exe just fine before by setting the
required ENVIRONMENT variables. That's what we use for the run-tests cmd in our
tree (all platforms), it supports post/upload/get as well.
Am I mistaken or what this application does is to remote control IE to load a
given URL? This URL being the test we like to test, from the document root? If
yes, that's something relatively easy to do using PHP directly (php supports
http natively btw). It is also easy to run the test using a given users using
runas, that does not match 100% the configuration of IIS+FCGI, but from a PHP
only point of view, it covers all cases.
Btw, take a look at the server scripts in the php src tree.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
On Mon, Feb 1, 2010 at 8:59 PM, Venkat Raman Don
<don.ra...@microsoft.com> wrote:
> Hi Pierre,
>
> Thanks for the comments.
>
> I am aware of the fact that we can test php-cgi.exe in various scenarios
> which is very close to real world. But my code gives the ability to test
> php-cgi.exe exactly like real world. Most of the people use PHP to host some
> application. It can be home grown application, a community application or a
> variance of a community application. This is exactly what the code simulates.
> And one more clarification it is not dependent on any server or how one has
> configured to run PHP. It can be IIS/APACHE (or any other server for that
> matter) and is also not dependent on how you server is configured. It can be
> mod_php/FastCGI/ISAPI etc. So far as your code can run in the browser, the
> driver has the ability to test it. The only flaw is that it runs primarily on
> WINDOWS as it takes a hard dependency on Internet Explorer being the browser.
> I believe if we found this useful the hard dependency can be removed.
Right, but you don't need IE for that unless you want to test the JS
script inside IE (but that's not cgi related then), or do
screenshots/compare contents. The later can done using php only with
COM btw (and gd for the shots) :)
The server scripts in our source could be a good start (at least to
get some ideas), I got some inspiration from them for our tests suite.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--- End Message ---
--- Begin Message ---
Hi,
A good idea about using COM/GD. Let's talk about some pro/cons of it and the
solution I gave.
1. COM never worked with default IIS configuration because of permission
issues. This means again you are not simulating a real world scenario.
2. COM based solution will never have the ability to be ported to UNIX world.
3. GD can be used for screenshot comparison but any screenshot comparison will
have some error of margin. Plus your thing (expected output) will be dependent
on screen resolution/display settings etc. If your code has to be portable
going this route is not a good idea in my view.
Regarding dependency on IE, I see no reason why we cannot use a Mozilla based
browser and automate it. That way it can work on any platform though it will
have its own challenges but not the ones we will face using GD and COM.
Thanks,
Don.
-----Original Message-----
From: Pierre Joye [mailto:pierre....@gmail.com]
Sent: Monday, February 01, 2010 12:09 PM
To: Venkat Raman Don
Cc: php-wind...@lists.php.net
Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
On Mon, Feb 1, 2010 at 8:59 PM, Venkat Raman Don <don.ra...@microsoft.com>
wrote:
> Hi Pierre,
>
> Thanks for the comments.
>
> I am aware of the fact that we can test php-cgi.exe in various scenarios
> which is very close to real world. But my code gives the ability to test
> php-cgi.exe exactly like real world. Most of the people use PHP to host some
> application. It can be home grown application, a community application or a
> variance of a community application. This is exactly what the code simulates.
> And one more clarification it is not dependent on any server or how one has
> configured to run PHP. It can be IIS/APACHE (or any other server for that
> matter) and is also not dependent on how you server is configured. It can be
> mod_php/FastCGI/ISAPI etc. So far as your code can run in the browser, the
> driver has the ability to test it. The only flaw is that it runs primarily on
> WINDOWS as it takes a hard dependency on Internet Explorer being the browser.
> I believe if we found this useful the hard dependency can be removed.
Right, but you don't need IE for that unless you want to test the JS script
inside IE (but that's not cgi related then), or do screenshots/compare
contents. The later can done using php only with COM btw (and gd for the shots)
:)
The server scripts in our source could be a good start (at least to get some
ideas), I got some inspiration from them for our tests suite.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--- End Message ---
--- Begin Message ---
On Mon, Feb 1, 2010 at 9:59 PM, Venkat Raman Don
<don.ra...@microsoft.com> wrote:
> Hi,
>
> A good idea about using COM/GD. Let's talk about some pro/cons of it and the
> solution I gave.
> 1. COM never worked with default IIS configuration because of permission
> issues. This means again you are not simulating a real world scenario.
> 2. COM based solution will never have the ability to be ported to UNIX world.
> 3. GD can be used for screenshot comparison but any screenshot comparison
> will have some error of margin. Plus your thing (expected output) will be
> dependent on screen resolution/display settings etc. If your code has to be
> portable going this route is not a good idea in my view.
>
> Regarding dependency on IE, I see no reason why we cannot use a Mozilla based
> browser and automate it. That way it can work on any platform though it will
> have its own challenges but not the ones we will face using GD and COM.
Sorry, I was not clear. My point was: There is no need of a browser to
do http requests and compare the output.
For test client side results (visuallly, js, etc.), there are
excellent tools out there like selenium, but that's not what we
discuss here.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--- End Message ---
--- Begin Message ---
Hi,
Let's don't argue just for the heck of it.
Can I know why browser is not a good thing. And what solution you are arriving
into. And can you help me share the coding for that solution if we find it
better. And BTW my solution doesn't involve comparing screenshot.
I think I have given enough reason why not to use GD/COM. Do you still think
using COM/GD is a viable option? Or you have another alternative? I already
told you we can use Mozilla based browser which can be used across platform.
Ideally a solution should be scalable and work on different matrix.
Thanks,
Don.
-----Original Message-----
From: Pierre Joye [mailto:pierre....@gmail.com]
Sent: Monday, February 01, 2010 1:04 PM
To: Venkat Raman Don
Cc: php-wind...@lists.php.net
Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
On Mon, Feb 1, 2010 at 9:59 PM, Venkat Raman Don
<don.ra...@microsoft.com> wrote:
> Hi,
>
> A good idea about using COM/GD. Let's talk about some pro/cons of it and the
> solution I gave.
> 1. COM never worked with default IIS configuration because of permission
> issues. This means again you are not simulating a real world scenario.
> 2. COM based solution will never have the ability to be ported to UNIX world.
> 3. GD can be used for screenshot comparison but any screenshot comparison
> will have some error of margin. Plus your thing (expected output) will be
> dependent on screen resolution/display settings etc. If your code has to be
> portable going this route is not a good idea in my view.
>
> Regarding dependency on IE, I see no reason why we cannot use a Mozilla based
> browser and automate it. That way it can work on any platform though it will
> have its own challenges but not the ones we will face using GD and COM.
Sorry, I was not clear. My point was: There is no need of a browser to
do http requests and compare the output.
For test client side results (visuallly, js, etc.), there are
excellent tools out there like selenium, but that's not what we
discuss here.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
