MIME-Version: 1.0
In-Reply-To: 
 <CAKmZXFRvn8JDL52ooxZYtrf0Aw+bMz6=spXmyP9Q7fq8kWjuDA@mail.gmail.com>
References: 
 <CAKmZXFQ2Hj1-OZpSGFEBB-vOypQ_=1b4Yr_VytZ-E1=CBw9Yhw@mail.gmail.com>
 <CA+OCxow8Q83e7Tm+BC2bxq=oqwd-m4JS3y2KpzgFemc=wX=f=A@mail.gmail.com>
 <CAKmZXFTX9D_qOXGrvPa9sfFjc1A6VPebcpBn7vyzPEOH4pWfEg@mail.gmail.com>
 <CAKmZXFRj8yY91TTxwQQ01eOQE8Rc7FPWuxGcjxaVY+QcWpgWDg@mail.gmail.com>
 <CA+OCxoyqfK8pUGGmeO=5pyC=MOizNMOnfshAfgQ5NjMRnkjgmA@mail.gmail.com>
 <CAKmZXFSgdtd9NDE=TysR68_tcwqFB2Sv-h+qK4K4i1HjxOd5ng@mail.gmail.com>
 <CAKmZXFRWXd7ZrUhpJt-rD_YOE1xcK5haE1CwAj8DMVyS9Fs6yA@mail.gmail.com>
 <CA+OCxoyiNMAem5bYAZ1XM16vK4wJETCCPncRgKYbVdmH2m4Ocg@mail.gmail.com>
 <CAKmZXFRvn8JDL52ooxZYtrf0Aw+bMz6=spXmyP9Q7fq8kWjuDA@mail.gmail.com>
From: Dave Page <dpage@pgadmin.org>
Date: Mon, 27 Jun 2016 08:54:03 +0100
Message-ID: 
 <CA+OCxowzMWyATh1_eEQ7hnrseaxuq8T3_+FDsCETLm=WaoRNEw@mail.gmail.com>
Subject: Re: pgAdmin IV API test cases patch
To: Priyanka Shendge <priyanka.shendge@enterprisedb.com>
Cc: pgadmin-hackers <pgadmin-hackers@postgresql.org>,
	Kanchan Mohitey <kanchan.mohitey@enterprisedb.com>
Content-Type: text/plain; charset=UTF-8
Precedence: bulk
Sender: pgadmin-hackers-owner@postgresql.org

On Sun, Jun 26, 2016 at 12:05 PM, Priyanka Shendge
<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 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  from
> test_config.json while execution.

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

>> 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.

>> >>> 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