Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bK2Yq-0006ba-6A for pgadmin-hackers@arkaria.postgresql.org; Mon, 04 Jul 2016 12:01:12 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bK2Yp-0006rw-5r for pgadmin-hackers@arkaria.postgresql.org; Mon, 04 Jul 2016 12:01:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bK2Ya-0006dg-BU for pgadmin-hackers@postgresql.org; Mon, 04 Jul 2016 12:00:56 +0000 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bK2YQ-0001Yx-AY for pgadmin-hackers@postgresql.org; Mon, 04 Jul 2016 12:00:55 +0000 Received: by mail-wm0-x22f.google.com with SMTP id a66so112629072wme.0 for ; Mon, 04 Jul 2016 05:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WCwg5mn+tZBZ+b+ftqKb/oa8cyaPi3YTUtGNOK6KQtY=; b=WBY8OO3CmcyXRwrXdSGfN5LHJ27Hs+BG3Zk3nP670WNIBbeaMVuGyVNVy3YcSUeUwl EprWgyUwwe9eVxGTpBbFWOpsZmBU+Qiy9EEHqZJFoUFp+7+AuAooTaiYwebrV7VEUAPC mCBF0Rqxl16lGrCss7A/Y9yNklwkGbGm9HIU9rZk8GlFxtW5zrTC8nFY8OI6UwVJcJul +K2TBHk2+DlpfkZBuPPjiy1zOtN0JoA/5aYC/MiDM6e30pdfeQVUztGkb2JWl8y6Rh6O H8T+pC4P3Z3QQzcD9yS4ejX8MRvxMLGsdpn9mkhFiRVO/g+dz6Vm4rkCY5lno2BspvOI Q28w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WCwg5mn+tZBZ+b+ftqKb/oa8cyaPi3YTUtGNOK6KQtY=; b=AtTxhba40A1HmFf1wAzSCp5BxRZObTMBkzJrAF92AR48Bkp7688u5VudiLyJdNHlcf xcg5faQY3lulQB/14kdeoMk5GDQZ1+00aD8HeliqQKvrLNNDmavGEpAc5gwxlsYEU+hE TTBWDm4qxnJxmSTgXwelYEGbskB6XQ+aBbsgFslY8bPo0wibwcRmxhGPyujz0dGrMnU1 eH1aq18I3qwvTtBQPH2D1zI+FqnfWzxiN+Pbg09sg8FPnuAmC/96ynTS8POQLkYExEIw srV7jGsz4fHhWjZjbjmPPnC4x8WHPIgdTzrwjHxiG+bVMgGf43Fo2LtkOWs9fyroUD5G UffQ== X-Gm-Message-State: ALyK8tK7DTSByCS6GoQZyRHeL8ATc764EV8Jvo9CHhvkJYV17QLm6DGhtWjBFuCp8HqTIw== X-Received: by 10.28.141.4 with SMTP id p4mr11010817wmd.46.1467633643264; Mon, 04 Jul 2016 05:00:43 -0700 (PDT) Received: from [192.168.203.228] ([83.217.96.157]) by smtp.gmail.com with ESMTPSA id ej9sm4155016wjd.7.2016.07.04.05.00.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Jul 2016 05:00:39 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-F4A7CA97-B0BB-4A59-810E-777E7D964DF9 Mime-Version: 1.0 (1.0) Subject: Re: pgAdmin IV API test cases patch From: Dave Page X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Mon, 4 Jul 2016 13:00:37 +0100 Cc: pgadmin-hackers , Kanchan Mohitey Content-Transfer-Encoding: 7bit Message-Id: <1C830532-F2F0-4FBC-BD17-4428CE9AA53D@pgadmin.org> References: To: Priyanka Shendge 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 --Apple-Mail-F4A7CA97-B0BB-4A59-810E-777E7D964DF9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi The test data was the default, and I ran against PG 9.4. All other logs were= attached to my previous email. --=20 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: >=20 > Hi Dave, >=20 > 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 no= de?=20 >=20 > Thank you. >=20 >> On 30 June 2016 at 00:51, Dave Page wrote: >> Hi, >>=20 >> That's better. I tweaked a few things and fixed a bug related to >> recent changes to the schema version config. Patch attached. >>=20 >> However, there are still issues: >>=20 >> 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. >>=20 >> Thanks. >>=20 >>=20 >> 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 n= ever >> >>> >> >>> 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 conta= ins >> >>> >> > 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 respec= tive >> >>> > 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) int= o >> >>> > test_config.json >> >>> > instead taking care of each field? >> >>> >> >>> You should have one set of credentials that's used for the entire tes= t >> >>> run. >> >> >> >> >> >> Sure. I'll separate the credentials and test data into 2 different fi= les. >> >> 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 pu= t it >> >>> >> >>> in >> >>> >> >>> a different file to avoid confusing/scaring everyone else. May= be >> >>> >> >>> 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 sim= ple >> >>> >> file, and just add database server details for the server to run >> >>> >> against. >> >>> >> >> >>> >> - If we have configurable tests (because making them configurable a= dds >> >>> >> 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. Th= at'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 f= ile >> >>> >> (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 >>=20 >>=20 >>=20 >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >>=20 >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >=20 >=20 >=20 > --=20 > Best, > Priyanka >=20 > EnterpriseDB Corporation > The Enterprise PostgreSQL Company --Apple-Mail-F4A7CA97-B0BB-4A59-810E-777E7D964DF9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi

The test data was the default, and= I ran against PG 9.4. All other logs were attached to my previous email.
-- 
D= ave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK:http://www.enterprisedb.com
The Enterprise PostgreSQL Com= pany

On 4 Jul 2016, at 12:16, Priyanka Shendge <priyanka.shendge@enterprise= db.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 D= EBUG logs and test data using for database node? 

<= div>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 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
<priyanka.shendge@enterprisedb.com> 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
> <priyanka.shend= ge@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 Shendge
>>> <priyan= ka.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, Priyanka 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> wrote:
>>> >> >>>
>>> >> >>> Hi
>>> >> >>>
>>> >> >>> On Thu, Jun 9, 2016 at 1:37 PM, Priyanka S= hendge
>>> >> >>> <priyanka.shendge@enterprisedb.com> wrote:
>>> >> >>> > Hi Dave,
>>> >> >>> >
>>> >> >>> > PFA updated patch. I have made chang= es suggested by you.
>>> >> >>> >
>>> >> >>> > Kindly, review and let me know for m= ore changes.
>>> >> >>>
>>> >> >>> OK, I got a bit further this time, but no= t there yet.
>>> >> >>>
>>> >> >>> 1) The patch overwrote my test_config.jso= n file. That should never
>>> >> >>> happen (that file shouldn't be in the sou= rce tree).
>>> >> >>> test_config.json.in should be the fil= e that's included in the
>>> >> >>> patch.
>>> >> >>
>>> >> >>
>>> >> >> OK.
>>> >> >>>
>>> >> >>>
>>> >> >>> 2) The updated test_config.json file is h= uge.
>>> >> >
>>> >> >
>>> >> > Current configuration file web/regression/test_co= nfig.json contains
>>> >> > test
>>> >> > data(credentials) for each tree node;
>>> >> > which is used while adding and updating the respe= ctive node.
>>> >>
>>> >> Why would we need that?
>>> >
>>> >
>>> > Each node file (e.g. test_db_add.py and test_db_put.py) us= es respective
>>> > credentials test data  from
>>> > test_config.json while execution.
>>>
>>> That doesn't answer my question - why do we need separate crede= ntials
>>> 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, sc= hema) into
>>> > test_config.json
>>> > instead  taking care of each field?
>>>
>>> You should have one set of credentials that's used for the enti= re test
>>> run.
>>
>>
>> Sure.  I'll separate the credentials and test data into 2 diff= erent 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 h= e
>> wants.
>>>
>>>
>>> >> >>> I should only need to
>>> >> >>> define one or more connections, then be a= ble to run the tests. If
>>> >> >>> you
>>> >> >>> need to keep configuration info for "adva= nced users", let's put it
>>> >> >>> in
>>> >> >>> a different file to avoid confusing/scari= ng everyone else. Maybe
>>> >> >>> split
>>> >> >>> it into config.json for the stuff the use= r 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 n= ot, why are the
>>> >> values not just hard-coded?
>>> >>
>>> >> > e.g. for database node:
>>> >> > I'll create config.json file into .../databases/t= ests/ directory
>>> >> > put database add and update credentials into conf= ig.json
>>> >>
>>> >> The key here is to make it simple for users.
>>> >>
>>> >> - To run the default tests, they should be able to cop= y/edit a simple
>>> >> file, and just add database server details for the ser= ver to run
>>> >> against.
>>> >>
>>> >> - If we have configurable tests (because making them c= onfigurable adds
>>> >> genuine value), then we can use an "advanced" config f= ile 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 fo= llowing:
>>> >>
>>> >> - 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 t= ests should
>>> >> have defaults that match what is in the template advan= ced config file
>>> >> (or, the tests could read advanced.json.in if advance= d.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/pgadm= in-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



--
<= div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">
Best,
Priyanka

EnterpriseDB Corporation
The Enterprise PostgreSQL Company<= /font>
= --Apple-Mail-F4A7CA97-B0BB-4A59-810E-777E7D964DF9--