Re: [pgadmin-hackers] Acceptance Tests against a browser (WIP)
От | George Gelashvili |
---|---|
Тема | Re: [pgadmin-hackers] Acceptance Tests against a browser (WIP) |
Дата | |
Msg-id | CAHowoHbXL2wu2feErTTWhgmcM4=48KATZkvguGRiy-UNNW-mfQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [pgadmin-hackers] Acceptance Tests against a browser (WIP) (Dave Page <dpage@pgadmin.org>) |
Ответы |
Re: [pgadmin-hackers] Acceptance Tests against a browser (WIP)
(Dave Page <dpage@pgadmin.org>)
|
Список | pgadmin-hackers |
Hi Dave,
We agree that a random port would be a nice addition. We think having randomized test database names can lead to polluting with lots of extra databases left around in the event that cleanup fails for whatever reason (e.g. a test errors out). We see this happen already with the randomized test databases you mention. We agree that there should probably be one strategy across the test suite. We could use randomized names and have a more general cleanup step that removes all databases of the form "test_...".
Dave, are those errors you saw when you shut down your application on :5050 and did a fresh run of the tests? If not, could you please do a clean run? It's possible that the second error could be related to viewport size as you suggested, but the first error just looks like a problem with the test not being able to spin up its own server.
Thanks,
George & Tira
On Tue, Jan 31, 2017 at 9:41 AM, Dave Page <dpage@pgadmin.org> wrote:
Hi
On Mon, Jan 30, 2017 at 9:23 PM, Atira Odhner <aodhner@pivotal.io> wrote:
> Here's the patch with one more fix -- cleaning up the connections that get
> created in pgAdmin.
Hmm, I had trouble with this one. I noticed a few issues:
- The tests started pgAdmin listening on the default port (5050),
however, I already had an instance running on there;
a) It should have detected that something else was running on the port
b) Shouldn't we just use a random, unused port?
- Errors were given because I already had an acceptance_test_db on a
number of servers, and that contained the test table. Obviously the
code now cleans up after itself, but I think we should use a random
database name as the main regression tests do (they append a random
number to the name iirc).
- Some of the tests just seemed to time out. I *think* this might be
because the test browser window opens quite narrowly, and it looks
like the tests are probably trying to do things with nodes that aren't
actually visible.
============================================================ ==========
ERROR: runTest (pgadmin.acceptance.tests.connect_to_server_feature_ test. ConnectsToServerFeatureTest)
------------------------------------------------------------ ----------
Traceback (most recent call last):
File "/Users/dpage/git/pgadmin4/web/pgadmin/acceptance/tests/ connect_to_server_feature_ test.py",
line 69, in tearDown
self.app_starter.stop_app()
File "/Users/dpage/git/pgadmin4/web/regression/utils/app_ starter.py",
line 27, in stop_app
os.killpg(os.getpgid(self.pgadmin_process.pid), signal.SIGTERM)
OSError: [Errno 3] No such process
============================================================ ==========
ERROR: runTest (pgadmin.acceptance.tests.sql_template_selection_by_ postgres_version_works_ feature_test. SQLTemplateSelectionByPostgres VersionWorksFeatureTest)
------------------------------------------------------------ ----------
Traceback (most recent call last):
File "/Users/dpage/git/pgadmin4/web/pgadmin/acceptance/tests/ sql_template_selection_by_ postgres_version_works_ feature_test.py",
line 37, in runTest
self.page.find_by_xpath("//*[@id='tree']//*[@class=' aciTreeText'
and .='Trigger Functions']").click()
File "/Users/dpage/git/pgadmin4/web/regression/utils/pgadmin_ page.py",
line 45, in find_by_xpath
return self.wait_for_element(lambda:
self.driver.find_element_by_xpath(xpath))
File "/Users/dpage/git/pgadmin4/web/regression/utils/pgadmin_ page.py",
line 72, in wait_for_element
return self._wait_for("element to exist", element_if_it_exists)
File "/Users/dpage/git/pgadmin4/web/regression/utils/pgadmin_ page.py",
line 106, in _wait_for
raise RuntimeError("timed out waiting for " + waiting_for_message)
RuntimeError: timed out waiting for element to exist
============================================================ ==========
ERROR: runTest (pgadmin.acceptance.tests.sql_template_selection_by_ postgres_version_works_ feature_test. SQLTemplateSelectionByPostgres VersionWorksFeatureTest)
------------------------------------------------------------ ----------
Traceback (most recent call last):
File "/Users/dpage/git/pgadmin4/web/pgadmin/acceptance/tests/ sql_template_selection_by_ postgres_version_works_ feature_test.py",
line 60, in tearDown
self.page.find_by_xpath("//button[contains(.,'Cancel')]") .click()
File "/Users/dpage/git/pgadmin4/web/regression/utils/pgadmin_ page.py",
line 45, in find_by_xpath
return self.wait_for_element(lambda:
self.driver.find_element_by_xpath(xpath))
File "/Users/dpage/git/pgadmin4/web/regression/utils/pgadmin_ page.py",
line 72, in wait_for_element
return self._wait_for("element to exist", element_if_it_exists)
File "/Users/dpage/git/pgadmin4/web/regression/utils/pgadmin_ page.py",
line 106, in _wait_for
raise RuntimeError("timed out waiting for " + waiting_for_message)
RuntimeError: timed out waiting for element to exist
------------------------------------------------------------ ----------
Thanks.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
В списке pgadmin-hackers по дате отправления:
Предыдущее
От: Dave PageДата:
Сообщение: Re: [pgadmin-hackers] Acceptance Tests against a browser (WIP)
Следующее
От: Dave PageДата:
Сообщение: Re: [pgadmin-hackers] Acceptance Tests against a browser (WIP)