Re: Acceptance Tests against a browser (WIP)

From: George Gelashvili <ggelashvili(at)pivotal(dot)io>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Atira Odhner <aodhner(at)pivotal(dot)io>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Acceptance Tests against a browser (WIP)
Date: 2017-01-31 14:54:27
Message-ID: CAHowoHbXL2wu2feErTTWhgmcM4=48KATZkvguGRiy-UNNW-mfQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)pgadmin(dot)org> wrote:

> Hi
>
> On Mon, Jan 30, 2017 at 9:23 PM, Atira Odhner <aodhner(at)pivotal(dot)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("//*[(at)id='tree']//*[(at)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
>

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Dave Page 2017-01-31 15:10:04 Re: Acceptance Tests against a browser (WIP)
Previous Message Dave Page 2017-01-31 14:41:09 Re: Acceptance Tests against a browser (WIP)