Re: pgAdmin IV API test cases patch

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(dot)shendge(at)enterprisedb(dot)com> wrote:

>
>
> On 27 June 2016 at 13:24, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>> On Sun, Jun 26, 2016 at 12:05 PM, Priyanka Shendge
>> <priyanka(dot)shendge(at)enterprisedb(dot)com> wrote:
>> >
>> >
>> > On 24 June 2016 at 16:17, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> >>
>> >> Hi
>> >>
>> >> On Thu, Jun 23, 2016 at 2:41 PM, Priyanka Shendge
>> >> <priyanka(dot)shendge(at)enterprisedb(dot)com> wrote:
>> >> >
>> >> >
>> >> > On 15 June 2016 at 15:05, Priyanka Shendge
>> >> > <priyanka(dot)shendge(at)enterprisedb(dot)com> wrote:
>> >> >>
>> >> >> Thanks a lot Dave.
>> >> >>
>> >> >> On 15 June 2016 at 14:09, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> >> >>>
>> >> >>> Hi
>> >> >>>
>> >> >>> On Thu, Jun 9, 2016 at 1:37 PM, Priyanka Shendge
>> >> >>> <priyanka(dot)shendge(at)enterprisedb(dot)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 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(at)postgresql(dot)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