Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bHT24-0001u5-Qo for pgadmin-hackers@arkaria.postgresql.org; Mon, 27 Jun 2016 09:40:45 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bHT24-0004K2-9g for pgadmin-hackers@arkaria.postgresql.org; Mon, 27 Jun 2016 09:40:44 +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 1bHT1q-000464-GY for pgadmin-hackers@postgresql.org; Mon, 27 Jun 2016 09:40:30 +0000 Received: from mail-qk0-x233.google.com ([2607:f8b0:400d:c09::233]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bHT1n-00026C-3f for pgadmin-hackers@postgresql.org; Mon, 27 Jun 2016 09:40:29 +0000 Received: by mail-qk0-x233.google.com with SMTP id p10so199665077qke.3 for ; Mon, 27 Jun 2016 02:40:26 -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=PIFG5aRJtVt9aCehY2szlAIyQankFiq0yYMMPZS1sZ4=; b=X9fv8WXOZaJhJ/X6d+Q6yfroU+qDMN3LrXgDiaLp2IadC5jLDinXE/97up7IJsgkb3 wSBPNj4mn1wcuy0ktVXULMt3bfbwfWGle/2raF7f6glcwI4tDo2CQLWtNqGf9wh6yC8w NDf6JlOzgYMW7PZB5Ft5Nd3XYUa48ENlrjVDRRoecritVaaTGhCV7cZNQOJiggwxsGE8 9aqZUzVK1NlX0im/mDywOArqPogLJVOBpvQUb2Jqxoq9FWJjgyhR7tS7vS2uJqa6Ep8F 4XZWNCzAth1Z5IQxAeJeXHZxRYKYkcLZNSTK0I4lDBB4GVpcSmr/UiLE8T26tqbuVyoT Dgdg== 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=PIFG5aRJtVt9aCehY2szlAIyQankFiq0yYMMPZS1sZ4=; b=mNKiDj25J0xJdI6EFXHwuCDV53LizP5kLVZo0pp/TcdeRrZWAoAfjdE1rSRErraBU0 Nwx6uwqt30NsWnDIcYaY+ybzcznKk1Oj6gw7nthXQDiKlJEqv1R0vXu4FcEe6gNT75XK UStXqC8sadOiFGIAh8YyCJ6uOg+PlppKTLO/kN2Uf9mRNZiR1qLDyKY5MS3CyF+e4/Lt wD2RRTH44yCxgnitrIg7eqez/VLAqmMoAlKU8VTNaOXGGfI1HOP1DBEdSWpkpDWDdHSC upeGoowBikCgz9uZCacB2pK5zEva7iTxzRmbQnnRtv7feebURwc4X94qEvQ0NMlrJ6Ao ibyg== X-Gm-Message-State: ALyK8tLsnmwOk3ZR+R4n27QGhE4z+QbkgQlO0BjzLlL0ys99j2avBHxYML+xvYIq0uYnmoggcUH1bYt3oFHM1xik X-Received: by 10.55.212.147 with SMTP id s19mr14708238qks.64.1467020426128; Mon, 27 Jun 2016 02:40:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.45.165 with HTTP; Mon, 27 Jun 2016 02:40:06 -0700 (PDT) In-Reply-To: References: From: Priyanka Shendge Date: Mon, 27 Jun 2016 15:10:06 +0530 Message-ID: Subject: Re: pgAdmin IV API test cases patch To: Dave Page Cc: pgadmin-hackers , Kanchan Mohitey Content-Type: multipart/alternative; boundary=001a1149af4a60c71c05363f4ff7 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 --001a1149af4a60c71c05363f4ff7 Content-Type: text/plain; charset=UTF-8 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 --001a1149af4a60c71c05363f4ff7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 27 June 2016 at 13:24, Dave Page <dpage@pgadmin.org> = wrote:
On Sun, Jun 26, 2016 at 12:05 PM, Priyanka Shend= ge
<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, 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 Shendge
>> >>> <priyanka.shendge@enterprisedb.com> 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 co= ntains test
>> > data(credentials) for each tree node;
>> > which is used while adding and updating the respective node.<= br> >>
>> Why would we need that?
>
>
> Each node file (e.g. test_db_add.py and test_db_put.py) uses respectiv= e
> credentials test data<= /span> =C2=A0from
> test_config.json while execution.

That doesn't answer my question - why do we need separate c= redentials
for each node?

Sorry for typo, its test= data not credentials.
=C2=A0

>> 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=C2=A0 taking care of each field?

You should have one set of credentials that's used for the entir= e test run.

Sure.=C2=A0 I'll separa= te the credentials and test data into 2 different files.
So, a no= rmal user can run the tests into one go after some minor credentials change= s.
And an advanced user can have an option to change the test dat= a if he wants.

>> >>> I should only need to
>> >>> define one or more connections, then be able to run t= he tests. If you
>> >>> need to keep configuration info for "advanced us= ers", 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 e= dit
>> >>> (config.json.in would go in git), and test_config.jso= n 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 respecti= ve 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/ di= rectory
>> > 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 = adds
>> genuine value), then we can use an "advanced" config fil= e 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 doe= sn't
>> exist, though that does seem a little icky). Of course, those are<= br> >> 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<= /a>)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers=



--
Best,
Priyanka

EnterpriseDB Corpora= tion
The Enterprise PostgreSQL Company
--001a1149af4a60c71c05363f4ff7--