Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bLSF7-0000cQ-3l for pgadmin-hackers@arkaria.postgresql.org; Fri, 08 Jul 2016 09:38:41 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bLSF6-0005sB-ND for pgadmin-hackers@arkaria.postgresql.org; Fri, 08 Jul 2016 09:38:40 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bLSF4-0005p5-Sk for pgadmin-hackers@postgresql.org; Fri, 08 Jul 2016 09:38:39 +0000 Received: from mail-qt0-x229.google.com ([2607:f8b0:400d:c0d::229]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bLSF0-0002PE-U4 for pgadmin-hackers@postgresql.org; Fri, 08 Jul 2016 09:38:37 +0000 Received: by mail-qt0-x229.google.com with SMTP id f89so20379324qtd.2 for ; Fri, 08 Jul 2016 02:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2SH8T06JbSv54tV1S+wXvHIIZiYTCzGs/C2QjXVYLCo=; b=qjTo3ATaUFx5UNxrINldbJiQ5mntsNFhcRsFOpULsdT+s1qYDLZY1yOERlYQ408YYZ byMGnLhvQDhnXI/UdPQCaY8KRwgrtjyiqtMHKw4M/p8dvCZZIaWPR0DEMEBGqPVvDQxd S/PXbz/wc1IiUWlU6qJsFBgovNRriebagWj+/wrzfyNlq5s1uI6ry3yHmRhyqsin+gIq g9ny743KphbSn2iXFBfmOmhxDzv4ktIT3jdQ6Gw5XN91IRXSfsCVLT/5kBvI3Wg8S1r3 GgrYFzFhKqjvdF+w8De7kolhyxNgp/JkPepisHscm/47syI9QaUGkMUYwB9HVdAZ6WeF 0UNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2SH8T06JbSv54tV1S+wXvHIIZiYTCzGs/C2QjXVYLCo=; b=Go/DvE+TyFrbWLUwiYfA1JXIPMKztGZByPUVUn7bkVLd0tK7Q/6WH7J9hWZSdUdVCM 1CY0vv3XVpt9aCPA5ch+y0ne91XVkegDLk/WVA/Vcyv+TJQMGBQlk+FjaqY4Pqdawrdn hAF0tKJGFs8745eidKT4It4pRZDaB0hvtS2hKZQE2eNUY0ycD4MK6IIzIXXIRL4mJVtN 0CkfuRDV8/KEcWqv1PIEewU1dEvEBs8FNimAofvvRHT0AHlU0fv3CQmwkUyVhfByDUGD HzgsbeEghOu8QMBKKYUbjEUuwLsjfm/T+Fw+aMRyPMi2CdIyEAOpACVq4RJ/ChQ32ERR UDPw== X-Gm-Message-State: ALyK8tLPpmQ7O8+irQeEwVUB0sOTAkRizjKwM3CwAQxk5wyx+hzKcIJXydH0cWL3HyQI2pHEqL+FTjxBvsoTEQ/3 X-Received: by 10.237.47.228 with SMTP id m91mr6851511qtd.35.1467970713777; Fri, 08 Jul 2016 02:38:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.45.165 with HTTP; Fri, 8 Jul 2016 02:38:14 -0700 (PDT) In-Reply-To: References: <1C830532-F2F0-4FBC-BD17-4428CE9AA53D@pgadmin.org> From: Priyanka Shendge Date: Fri, 8 Jul 2016 15:08:14 +0530 Message-ID: Subject: Re: pgAdmin IV API test cases patch To: Dave Page Cc: pgadmin-hackers , Kanchan Mohitey Content-Type: multipart/alternative; boundary=94eb2c12522aef916005371c90ac X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --94eb2c12522aef916005371c90ac Content-Type: text/plain; charset=UTF-8 Hi Dave, I have tried to reproduce the issue by running the test-suite on different machines (64 and 32 bit) and users on PG9.4/9.5 (Provided different "test_db_username" in test_config.json). It is working fine at my end. The log file (output.log) sent by you shows following query is failing at your end: SELECT db.oid as did, db.datname, db.datallowconn, pg_encoding_to_char(db.encoding) AS serverencoding, has_database_privilege(db.oid, 'CREATE') as cancreate, datlastsysoid FROM pg_database db WHERE db.oid = Let me know if you have an extra system where I can reproduce the issue. On 5 July 2016 at 15:40, Dave Page wrote: > Attached. > > On Tue, Jul 5, 2016 at 9:00 AM, Priyanka Shendge > wrote: > > Hi Dave, > > > > I tried running the testsuite against PG9.4 and unable to reproduce the > > failures. > > I have added debug statements to previous patch. Patch attached. > > Could you please re-run the same and send me the logs and output? > > > > Thank you. > > > > On 4 July 2016 at 17:30, Dave Page wrote: > >> > >> Hi > >> > >> The test data was the default, and I ran against PG 9.4. All other logs > >> were attached to my previous email. > >> > >> -- > >> Dave Page > >> Blog: http://pgsnake.blogspot.com > >> Twitter: @pgsnake > >> > >> EnterpriseDB UK:http://www.enterprisedb.com > >> The Enterprise PostgreSQL Company > >> > >> On 4 Jul 2016, at 12:16, Priyanka Shendge > >> wrote: > >> > >> Hi Dave, > >> > >> I am unable to reproduce issue on my side; tried on Python 2.7 and > Python > >> 3.4. > >> Could you please provide me DEBUG logs and test data using for database > >> node? > >> > >> Thank you. > >> > >> On 30 June 2016 at 00:51, Dave Page wrote: > >>> > >>> Hi, > >>> > >>> That's better. I tweaked a few things and fixed a bug related to > >>> recent changes to the schema version config. Patch attached. > >>> > >>> However, there are still issues: > >>> > >>> 1) The testsuite doesn't run to completion. See the attached > >>> stdout.txt and logger.txt files. > >>> 2) stdout should only display the test summary - what tests are > >>> currently running (and pass/fail), and a summary at the end - even if > >>> there's a crash like I saw. > >>> 3) The output log file should contain the full output, including > >>> what's sent to stdout. > >>> 4) The output advises the user to check ".../pgadmin4/web/regression". > >>> This should be in the summary at the end, and should be corrected to > >>> show the correct (full) path. > >>> > >>> Thanks. > >>> > >>> > >>> On Wed, Jun 29, 2016 at 2:52 PM, Priyanka Shendge > >>> wrote: > >>> > Hi Dave, > >>> > > >>> > As per discussion over mail i have created separate config files for > >>> > credentials and test data. > >>> > > >>> > PFA patch for same. Kindly, review and let me know for modifications. > >>> > > >>> > On 27 June 2016 at 15:10, Priyanka Shendge > >>> > wrote: > >>> >> > >>> >> > >>> >> > >>> >> On 27 June 2016 at 13:24, Dave Page wrote: > >>> >>> > >>> >>> On Sun, Jun 26, 2016 at 12:05 PM, Priyanka Shendge > >>> >>> wrote: > >>> >>> > > >>> >>> > > >>> >>> > On 24 June 2016 at 16:17, Dave Page wrote: > >>> >>> >> > >>> >>> >> Hi > >>> >>> >> > >>> >>> >> On Thu, Jun 23, 2016 at 2:41 PM, Priyanka Shendge > >>> >>> >> wrote: > >>> >>> >> > > >>> >>> >> > > >>> >>> >> > On 15 June 2016 at 15:05, Priyanka Shendge > >>> >>> >> > wrote: > >>> >>> >> >> > >>> >>> >> >> Thanks a lot Dave. > >>> >>> >> >> > >>> >>> >> >> On 15 June 2016 at 14:09, Dave Page > wrote: > >>> >>> >> >>> > >>> >>> >> >>> Hi > >>> >>> >> >>> > >>> >>> >> >>> On Thu, Jun 9, 2016 at 1:37 PM, Priyanka Shendge > >>> >>> >> >>> wrote: > >>> >>> >> >>> > Hi Dave, > >>> >>> >> >>> > > >>> >>> >> >>> > PFA updated patch. I have made changes suggested by you. > >>> >>> >> >>> > > >>> >>> >> >>> > Kindly, review and let me know for more changes. > >>> >>> >> >>> > >>> >>> >> >>> OK, I got a bit further this time, but not there yet. > >>> >>> >> >>> > >>> >>> >> >>> 1) The patch overwrote my test_config.json file. That should > >>> >>> >> >>> never > >>> >>> >> >>> happen (that file shouldn't be in the source tree). > >>> >>> >> >>> test_config.json.in should be the file that's included in > the > >>> >>> >> >>> patch. > >>> >>> >> >> > >>> >>> >> >> > >>> >>> >> >> OK. > >>> >>> >> >>> > >>> >>> >> >>> > >>> >>> >> >>> 2) The updated test_config.json file is huge. > >>> >>> >> > > >>> >>> >> > > >>> >>> >> > Current configuration file web/regression/test_config.json > >>> >>> >> > contains > >>> >>> >> > test > >>> >>> >> > data(credentials) for each tree node; > >>> >>> >> > which is used while adding and updating the respective node. > >>> >>> >> > >>> >>> >> Why would we need that? > >>> >>> > > >>> >>> > > >>> >>> > Each node file (e.g. test_db_add.py and test_db_put.py) uses > >>> >>> > respective > >>> >>> > credentials test data from > >>> >>> > test_config.json while execution. > >>> >>> > >>> >>> That doesn't answer my question - why do we need separate > credentials > >>> >>> for each node? > >>> >> > >>> >> > >>> >> Sorry for typo, its test data not credentials. > >>> >> > >>> >>> > >>> >>> > >>> >>> >> We should have just one set of credentials for > >>> >>> >> everything. > >>> >>> > > >>> >>> > > >>> >>> > Let me know if my understanding is clear: > >>> >>> > > >>> >>> > Should i keep basic credentials of each node (database, schema) > >>> >>> > into > >>> >>> > test_config.json > >>> >>> > instead taking care of each field? > >>> >>> > >>> >>> You should have one set of credentials that's used for the entire > >>> >>> test > >>> >>> run. > >>> >> > >>> >> > >>> >> Sure. I'll separate the credentials and test data into 2 different > >>> >> files. > >>> >> So, a normal user can run the tests into one go after some minor > >>> >> credentials changes. > >>> >> And an advanced user can have an option to change the test data if > he > >>> >> wants. > >>> >>> > >>> >>> > >>> >>> >> >>> I should only need to > >>> >>> >> >>> define one or more connections, then be able to run the > tests. > >>> >>> >> >>> If > >>> >>> >> >>> you > >>> >>> >> >>> need to keep configuration info for "advanced users", let's > >>> >>> >> >>> put it > >>> >>> >> >>> in > >>> >>> >> >>> a different file to avoid confusing/scaring everyone else. > >>> >>> >> >>> Maybe > >>> >>> >> >>> split > >>> >>> >> >>> it into config.json for the stuff the user needs to edit > >>> >>> >> >>> (config.json.in would go in git), and test_config.json for > the > >>> >>> >> >>> test > >>> >>> >> >>> configuration. > >>> >>> >> > > >>> >>> >> > > >>> >>> >> > Should i keep login and server credentials into > >>> >>> >> > web/regression/test_config.json file and > >>> >>> >> > put respective node details into config.json file of > respective > >>> >>> >> > node's > >>> >>> >> > tests > >>> >>> >> > directory? > >>> >>> >> > >>> >>> >> Not if you expect users to need to edit them - and if not, why > are > >>> >>> >> the > >>> >>> >> values not just hard-coded? > >>> >>> >> > >>> >>> >> > e.g. for database node: > >>> >>> >> > I'll create config.json file into .../databases/tests/ > directory > >>> >>> >> > put database add and update credentials into config.json > >>> >>> >> > >>> >>> >> The key here is to make it simple for users. > >>> >>> >> > >>> >>> >> - To run the default tests, they should be able to copy/edit a > >>> >>> >> simple > >>> >>> >> file, and just add database server details for the server to run > >>> >>> >> against. > >>> >>> >> > >>> >>> >> - If we have configurable tests (because making them > configurable > >>> >>> >> adds > >>> >>> >> genuine value), then we can use an "advanced" config file to > allow > >>> >>> >> the > >>> >>> >> user to adjust settings as they want. > >>> >>> >> > >>> >>> >> In the simple case, the user should be able to run the tests > >>> >>> >> successfully within a minute or two from starting. > >>> >>> >> > >>> >>> >> In designing the layout for files etc, remember the following: > >>> >>> >> > >>> >>> >> - Users should never edit a file that is in our source control. > >>> >>> >> That's > >>> >>> >> why we have .in files that we expect them to copy. > >>> >>> >> > >>> >>> >> - Unless they're an advanced user, they shouldn't need to copy > the > >>> >>> >> config file for advanced options. That means that the tests > should > >>> >>> >> have defaults that match what is in the template advanced config > >>> >>> >> file > >>> >>> >> (or, the tests could read advanced.json.in if advanced.json > >>> >>> >> doesn't > >>> >>> >> exist, though that does seem a little icky). Of course, those > are > >>> >>> >> example filenames, not necessarily what you may choose. > >>> >>> >> > >>> >>> >> -- > >>> >>> >> Dave Page > >>> >>> >> Blog: http://pgsnake.blogspot.com > >>> >>> >> Twitter: @pgsnake > >>> >>> >> > >>> >>> >> EnterpriseDB UK: http://www.enterprisedb.com > >>> >>> >> The Enterprise PostgreSQL Company > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > -- > >>> >>> > Best, > >>> >>> > Priyanka > >>> >>> > > >>> >>> > EnterpriseDB Corporation > >>> >>> > The Enterprise PostgreSQL Company > >>> >>> > >>> >>> > >>> >>> > >>> >>> -- > >>> >>> Dave Page > >>> >>> Blog: http://pgsnake.blogspot.com > >>> >>> Twitter: @pgsnake > >>> >>> > >>> >>> EnterpriseDB UK: http://www.enterprisedb.com > >>> >>> The Enterprise PostgreSQL Company > >>> >>> > >>> >>> > >>> >>> -- > >>> >>> Sent via pgadmin-hackers mailing list > >>> >>> (pgadmin-hackers@postgresql.org) > >>> >>> To make changes to your subscription: > >>> >>> http://www.postgresql.org/mailpref/pgadmin-hackers > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> Best, > >>> >> Priyanka > >>> >> > >>> >> EnterpriseDB Corporation > >>> >> The Enterprise PostgreSQL Company > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > Best, > >>> > Priyanka > >>> > > >>> > EnterpriseDB Corporation > >>> > The Enterprise PostgreSQL Company > >>> > >>> > >>> > >>> -- > >>> Dave Page > >>> Blog: http://pgsnake.blogspot.com > >>> Twitter: @pgsnake > >>> > >>> EnterpriseDB UK: http://www.enterprisedb.com > >>> The Enterprise PostgreSQL Company > >> > >> > >> > >> > >> -- > >> Best, > >> Priyanka > >> > >> EnterpriseDB Corporation > >> The Enterprise PostgreSQL Company > > > > > > > > > > -- > > Best, > > Priyanka > > > > EnterpriseDB Corporation > > The Enterprise PostgreSQL Company > > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Best, Priyanka EnterpriseDB Corporation The Enterprise PostgreSQL Company --94eb2c12522aef916005371c90ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,

I have tried to reproduce the = issue by running the test-suite on different machines (64 and 32 bit) and
users on PG9.4/9.5 (Provided different "test_db_username"= ; in test_config.json). It is working fine at my end.

<= div>The log file (output.log) sent by you shows following query is failing = at your end:

SELECT
=C2=A0 =C2=A0 d= b.oid as did, db.datname, db.datallowconn,
=C2=A0 =C2=A0 pg_encod= ing_to_char(db.encoding) AS serverencoding,
=C2=A0 =C2=A0 has_dat= abase_privilege(db.oid, 'CREATE') as cancreate, datlastsysoid
=
FROM
=C2=A0 =C2=A0 pg_database db
WHERE db.oid =3D=

Let me know if you have an extra system whe= re I can reproduce the issue.
=C2=A0

On 5 July 2016 at 15:40, Dave Page= <dpage@pgadmin.org> wrote:
<priyanka.shendge@enterprisedb.com> wrote:
> Hi Dave,
>
> I tried running the testsuite against PG9.4 and unable to reproduce th= e
> failures.
> I have added debug statements to previous patch. Patch attached.
> Could you please re-run the same and send me the logs and output?
>
> Thank you.
>
> On 4 July 2016 at 17:30, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>> The test data was the default, and I ran against PG 9.4. All other= logs
>> were attached to my previous email.
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK:http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>> On 4 Jul 2016, at 12:16, Priyanka Shendge
>> <priyanka.= shendge@enterprisedb.com> wrote:
>>
>> Hi Dave,
>>
>> I am unable to reproduce issue on my side; tried on Python 2.7 and= Python
>> 3.4.
>> Could you please provide me DEBUG logs and test data using for dat= abase
>> node?
>>
>> Thank you.
>>
>> On 30 June 2016 at 00:51, Dave Page <dpage@pgadmin.org> wrote:
>>>
>>> Hi,
>>>
>>> That's better. I tweaked a few things and fixed a bug rela= ted to
>>> recent changes to the schema version config. Patch attached. >>>
>>> However, there are still issues:
>>>
>>> 1) The testsuite doesn't run to completion. See the attach= ed
>>> stdout.txt and logger.txt files.
>>> 2) stdout should only display the test summary - what tests ar= e
>>> currently running (and pass/fail), and a summary at the end - = even if
>>> there's a crash like I saw.
>>> 3) The output log file should contain the full output, includi= ng
>>> what's sent to stdout.
>>> 4) The output advises the user to check ".../pgadmin4/web= /regression".
>>> This should be in the summary at the end, and should be correc= ted to
>>> show the correct (full) path.
>>>
>>> Thanks.
>>>
>>>
>>> On Wed, Jun 29, 2016 at 2:52 PM, Priyanka Shendge
>>> <priya= nka.shendge@enterprisedb.com> wrote:
>>> > Hi Dave,
>>> >
>>> > As per discussion over mail i have created separate confi= g files for
>>> > credentials and test data.
>>> >
>>> > PFA patch for same. Kindly, review and let me know for mo= difications.
>>> >
>>> > On 27 June 2016 at 15:10, Priyanka Shendge
>>> > <= priyanka.shendge@enterprisedb.com> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On 27 June 2016 at 13:24, Dave Page <dpage@pgadmin.org> wrote:
>>> >>>
>>> >>> On Sun, Jun 26, 2016 at 12:05 PM, Priyanka Shendg= e
>>> >>> <priyanka.shendge@enterprisedb.com> wrote:
>>> >>> >
>>> >>> >
>>> >>> > On 24 June 2016 at 16:17, Dave Page <dpage@pgadmin.org> wrote:
>>> >>> >>
>>> >>> >> Hi
>>> >>> >>
>>> >>> >> On Thu, Jun 23, 2016 at 2:41 PM, Priyank= a Shendge
>>> >>> >> <priyanka.shendge@enterprisedb.com> wrote:
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > On 15 June 2016 at 15:05, Priyanka = Shendge
>>> >>> >> > <priyanka.shendge@enterprisedb.com> wrote:
>>> >>> >> >>
>>> >>> >> >> Thanks a lot Dave.
>>> >>> >> >>
>>> >>> >> >> On 15 June 2016 at 14:09, Dave = Page <dpage@pgadmin.org> wro= te:
>>> >>> >> >>>
>>> >>> >> >>> Hi
>>> >>> >> >>>
>>> >>> >> >>> On Thu, Jun 9, 2016 at 1:37= PM, Priyanka Shendge
>>> >>> >> >>> <priyanka.shendge@enterprisedb.com> wro= te:
>>> >>> >> >>> > Hi Dave,
>>> >>> >> >>> >
>>> >>> >> >>> > PFA updated patch. I h= ave made changes suggested by you.
>>> >>> >> >>> >
>>> >>> >> >>> > Kindly, review and let= me know for more changes.
>>> >>> >> >>>
>>> >>> >> >>> OK, I got a bit further thi= s time, but not there yet.
>>> >>> >> >>>
>>> >>> >> >>> 1) The patch overwrote my t= est_config.json file. That should
>>> >>> >> >>> never
>>> >>> >> >>> happen (that file shouldn&#= 39;t be in the source tree).
>>> >>> >> >>> test_config.json.in sh= ould be the file that's included in the
>>> >>> >> >>> patch.
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >> OK.
>>> >>> >> >>>
>>> >>> >> >>>
>>> >>> >> >>> 2) The updated test_config.= json file is huge.
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > Current configuration file web/regr= ession/test_config.json
>>> >>> >> > contains
>>> >>> >> > test
>>> >>> >> > data(credentials) for each tree nod= e;
>>> >>> >> > which is used while adding and upda= ting the respective node.
>>> >>> >>
>>> >>> >> Why would we need that?
>>> >>> >
>>> >>> >
>>> >>> > Each node file (e.g. test_db_add.py and test= _db_put.py) uses
>>> >>> > respective
>>> >>> > credentials test data=C2=A0 from
>>> >>> > test_config.json while execution.
>>> >>>
>>> >>> That doesn't answer my question - why do we n= eed separate credentials
>>> >>> for each node?
>>> >>
>>> >>
>>> >> Sorry for typo, its test data not credentials.
>>> >>
>>> >>>
>>> >>>
>>> >>> >> We should have just one set of credentia= ls for
>>> >>> >> everything.
>>> >>> >
>>> >>> >
>>> >>> > Let me know if my understanding is clear: >>> >>> >
>>> >>> > Should i keep basic credentials of each node= (database, schema)
>>> >>> > into
>>> >>> > test_config.json
>>> >>> > instead=C2=A0 taking care of each field?
>>> >>>
>>> >>> You should have one set of credentials that's= used for the entire
>>> >>> test
>>> >>> run.
>>> >>
>>> >>
>>> >> Sure.=C2=A0 I'll separate the credentials and tes= t data into 2 different
>>> >> files.
>>> >> So, a normal user can run the tests into one go after= some minor
>>> >> credentials changes.
>>> >> And an advanced user can have an option to change the= test data if he
>>> >> wants.
>>> >>>
>>> >>>
>>> >>> >> >>> I should only need to
>>> >>> >> >>> define one or more connecti= ons, then be able to run the tests.
>>> >>> >> >>> If
>>> >>> >> >>> you
>>> >>> >> >>> need to keep configuration = info for "advanced users", let's
>>> >>> >> >>> put it
>>> >>> >> >>> in
>>> >>> >> >>> a different file to avoid c= onfusing/scaring everyone else.
>>> >>> >> >>> Maybe
>>> >>> >> >>> split
>>> >>> >> >>> it into config.json for the= stuff the user needs to edit
>>> >>> >> >>> (config.json.in would go in= git), and test_config.json for the
>>> >>> >> >>> test
>>> >>> >> >>> configuration.
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > Should i keep login and server cred= entials into
>>> >>> >> > web/regression/test_config.json fil= e and
>>> >>> >> > put respective node details into co= nfig.json file of respective
>>> >>> >> > node's
>>> >>> >> > tests
>>> >>> >> > directory?
>>> >>> >>
>>> >>> >> Not if you expect users to need to edit = them - and if not, why are
>>> >>> >> the
>>> >>> >> values not just hard-coded?
>>> >>> >>
>>> >>> >> > e.g. for database node:
>>> >>> >> > I'll create config.json file in= to .../databases/tests/ directory
>>> >>> >> > put database add and update credent= ials into config.json
>>> >>> >>
>>> >>> >> The key here is to make it simple for us= ers.
>>> >>> >>
>>> >>> >> - To run the default tests, they should = be able to copy/edit a
>>> >>> >> simple
>>> >>> >> file, and just add database server detai= ls for the server to run
>>> >>> >> against.
>>> >>> >>
>>> >>> >> - If we have configurable tests (because= making them configurable
>>> >>> >> adds
>>> >>> >> genuine value), then we can use an "= ;advanced" config file to allow
>>> >>> >> the
>>> >>> >> user to adjust settings as they want. >>> >>> >>
>>> >>> >> In the simple case, the user should be a= ble to run the tests
>>> >>> >> successfully within a minute or two from= starting.
>>> >>> >>
>>> >>> >> In designing the layout for files etc, r= emember the following:
>>> >>> >>
>>> >>> >> - Users should never edit a file that is= in our source control.
>>> >>> >> That's
>>> >>> >> why we have .in files that we expect the= m to copy.
>>> >>> >>
>>> >>> >> - Unless they're an advanced user, t= hey shouldn't need to copy the
>>> >>> >> config file for advanced options. That m= eans that the tests should
>>> >>> >> have defaults that match what is in the = template advanced config
>>> >>> >> file
>>> >>> >> (or, the tests could read advanced.json.in= if advanced.json
>>> >>> >> doesn't
>>> >>> >> exist, though that does seem a little ic= ky). Of course, those are
>>> >>> >> example filenames, not necessarily what = you may choose.
>>> >>> >>
>>> >>> >> --
>>> >>> >> Dave Page
>>> >>> >> Blog: http://pgsnake.blogspot.com<= br> >>> >>> >> Twitter: @pgsnake
>>> >>> >>
>>> >>> >> EnterpriseDB UK: http://www.enterprise= db.com
>>> >>> >> The Enterprise PostgreSQL Company
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > --
>>> >>> > Best,
>>> >>> > Priyanka
>>> >>> >
>>> >>> > EnterpriseDB Corporation
>>> >>> > The Enterprise PostgreSQL Company
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Dave Page
>>> >>> Blog: http://pgsnake.blogspot.com
>>> >>> Twitter: @pgsnake
>>> >>>
>>> >>> EnterpriseDB UK: http://www.enterprisedb.com
>>> >>> The Enterprise PostgreSQL Company
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Sent via pgadmin-hackers mailing list
>>> >>> (pgadmin-hackers@postgresql.org)
>>> >>> To make changes to your subscription:
>>> >>> http://www.postgresql.or= g/mailpref/pgadmin-hackers
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Best,
>>> >> Priyanka
>>> >>
>>> >> EnterpriseDB Corporation
>>> >> The Enterprise PostgreSQL Company
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Best,
>>> > Priyanka
>>> >
>>> > EnterpriseDB Corporation
>>> > The Enterprise PostgreSQL Company
>>>
>>>
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>
>>
>>
>>
>> --
>> Best,
>> Priyanka
>>
>> EnterpriseDB Corporation
>> The Enterprise PostgreSQL Company
>
>
>
>
> --
> Best,
> Priyanka
>
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



--
=
Best,
Priyanka

EnterpriseDB Corporation
The Enterprise PostgreSQL Co= mpany
--94eb2c12522aef916005371c90ac--