Fw: Use Test::Nginx with etcproxy and/or valgrind (Was Re: Test::Nginx::LWP vs. Test::Nginx::Socket)

[Antoine Bonavita]

Hello,

I started working on 2.2 and got a first working implementation. It's
currenly in my local git repository (a clone of yours on github.com).

I actually introduced 2 variables as the commit messages explain:

A. Added support for environment variable TEST_NGINX_NO_NGINX_MANAGER (defaults
    to 0) which will disable the nginx management code (stop/config/start).
    Very useful when you want to run tests on an already running NGINX (set
    TEST_NGINX_NO_NGINX_MANAGER to 1 and TEST_NGINX_CLIENT_PORT to the
    port your running nginx is listening on).
B. Added support for environment variable TEST_NGINX_FORCE_RESTART_ON_TEST.
    Defaults to 1. Must be explicitly set to 0 to avoid restarting the nginx
    server when the config does not change between two tests.
    This also brings support for allowing config not to be set.
    This way, using TEST_NGINX_FORCE_RESTART_ON_TEST=1 with TEST_NGINX_NO_SHUFFL
    and having a config section only on the first test, you can have all tests
    use the same config.

How do you want to proceed ? Should I fork your repo, commit my
changes on my fork and send you a pull request or should I send you
patches as diff ?

I think the whole stop/config/start code could use a little
refactoring but I didn't feel like doing this as well as this point:
I'd rather have things working first, then get on the refactoring. Let
me know what you think.

Antoine.

On Thu, Mar 17, 2011 at 4:42 AM, agentzh <agentzh at gmail.com> wrote:
> On Wed, Mar 16, 2011 at 5:38 PM, Antoine Bonavita (personal)
> <antoine.bonavita at gmail.com> wrote:
>> Thanks a lot for your time and openness.
>> I started thinking a little about all this and here are 3 suggestions
>> which I'm willing to work on if you think they are worth it:
>>
>> 1 - Regarding the ability to chain multiple requests in requests, the
>> only way I can think of is to make request and
>> error_code/response_body/response_body_like/etc. potential arrays and
>> adapt the code to handle arrays/strings. There is probably a lot of
>> impact on the code but I cannot think of any other way.
>
> I'm fine with this :)
>
>> 2 - Regarding the restart of nginx, I had two ideas:
>> 2.1 - Add a section (--- NO_RESTART). This is probably a very simple
>> solution but it relies on the order tests are run, so I think it can
>> be quite error-prone (especially if you shuffle tests and have
>> different configs).
>> 2.2 - Restart only when the config changes between two tests. This
>> behavior can even be controlled by something like
>> TEST_NGINX_FORCE_RESTART_ON_TEST which would happen to default to true
>> (to preserve current behavior).
>
> Option 2.2 is more attractive to me :)
>
>> 3 - Regarding the documentation, I was thinking of improving the doc
>> of Socket.pm by putting a small example next to each item (at least
>> the ones I know, I could not figure out the syntax of skip_nginx and
>> skip_nginx2). And maybe completely removing request_eval.
>>
>
> There's an example from ngx_drizzle's test suite for skip_nginx:
>
>    --- skip_nginx: 3: < 0.8.41
>
> That is, skipping 3 subtests, if and only if the current nginx version
> number is strictly less than 0.8.41.
>
> I'm not sure about the skip_nginx2 section for it was introduced by
> Piotr Sikora. Maybe Piotr is willing to comment on that? Piotr?
>
>> Let me know what you think.
>>
>
> I really appreciate your interest, time and contribution :)
>
> Thanks!
> -agentzh
>