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 < [email protected]> wrote: > > > On 27 June 2016 at 13:24, Dave Page <[email protected]> wrote: > >> On Sun, Jun 26, 2016 at 12:05 PM, Priyanka Shendge >> <[email protected]> wrote: >> > >> > >> > On 24 June 2016 at 16:17, Dave Page <[email protected]> wrote: >> >> >> >> Hi >> >> >> >> On Thu, Jun 23, 2016 at 2:41 PM, Priyanka Shendge >> >> <[email protected]> wrote: >> >> > >> >> > >> >> > On 15 June 2016 at 15:05, Priyanka Shendge >> >> > <[email protected]> wrote: >> >> >> >> >> >> Thanks a lot Dave. >> >> >> >> >> >> On 15 June 2016 at 14:09, Dave Page <[email protected]> wrote: >> >> >>> >> >> >>> Hi >> >> >>> >> >> >>> On Thu, Jun 9, 2016 at 1:37 PM, Priyanka Shendge >> >> >>> <[email protected]> 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 ([email protected]) >> 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
pgadmin4_config_revised.patch
Description: Binary data
-- Sent via pgadmin-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
