Re: PGweb: Patches and tests
От | Rodrigo Ramírez Norambuena |
---|---|
Тема | Re: PGweb: Patches and tests |
Дата | |
Msg-id | CAE9kuxMJsMSyGdMXYWp17_aNE2H_Oj6tCfnvAKRv9DWmodvAKg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PGweb: Patches and tests ("Jonathan S. Katz" <jkatz@postgresql.org>) |
Ответы |
Re: PGweb: Patches and tests
|
Список | pgsql-www |
On Wed, Sep 11, 2019 at 4:05 PM Jonathan S. Katz <jkatz@postgresql.org> wrote: > > Hi Rodrigo, > > Thank you for working on this, this is very exciting! :) > With patch 0002, I don't know if we have anything in production that > utilizes "loaddata" and as such am hesitant to update the > requirements.txt file. For that, I send a new patch to replace. I think is a better way to handle the dependencies, because in test environment we could need additional modules (0002-Split-requirement.txt-dependencies.patch) > > Can you please explain why you have allowed hosts set like that for > 0003? I have not needed to configure my development copy of pgweb to > have that. If you are working a different host (virtual-host, external IP, etc..) browser testing is against not localhost. The ALLOWED_HOST in '*' can resolve this trouble > > There a two main patches with tests > > > > - 0004-Refactor-Move-the-view-for-Robots-inside-a-text-file.patch > > - 0005-Refactor-Remove-extra-else-in-__str__-for-Quote.patch > > > > With that could build more test to maybe to help the deploy and CI > > process (I don't know if there any). > > This is definitely a good start given we should really be adding more > tests to pgweb in general. This does not need some work. > > [...] > > (Also please leave the documentation around that function in place :) I > don't feel that the tests should replace the documentation around the code.) > > The test case itself looks fine. I would suggest we maybe pick a > filename / structure that makes it clear that these are tests for the views. For this, add the patch 0005-Add-tests-for-robots-core-view.patch > For 0005, I would not put that in a migration. I would put that in a > test runner or whatever script we will use to build the test > environment, to mock varnish (if we need to -- not sure if we do?). Mock the varnish in first step could be more obfuscate because a purge_urls is present in the almost all models. The kick start is a add sql into db as varnish_local, after that could add a helper to test varnish function to load these functions in db. About not put in migration seams good choice but this migration run only in test model. I'll could find a other way to add for the runner or more clean. If you have any idea about this let me know. > Similarly, I think we should decide on how we want to store our tests to > differentiate between models / views. In the past, I've had > subdirectories in my test folders to distinguish this, but IIRC it > requires a custom testrunner. Ahm. i think we should keep the struct app/tests/test_{models, views, admin}.py > > I would be fine with accepting the change to the if/else on its own, as > it eliminates the superfluous "else" if there is no opposition to that. > > Thanks! Looking forward to seeing testing in the pgweb codebase :) Your welcome! -- Rodrigo Ramírez Norambuena http://www.rodrigoramirez.com/
Вложения
В списке pgsql-www по дате отправления: