Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYZpa-00046D-HD for pgadmin-hackers@arkaria.postgresql.org; Tue, 31 Jan 2017 14:54:50 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cYZpZ-0006WQ-CD for pgadmin-hackers@arkaria.postgresql.org; Tue, 31 Jan 2017 14:54:49 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cYZpL-0006HY-1V for pgadmin-hackers@postgresql.org; Tue, 31 Jan 2017 14:54:35 +0000 Received: from mail-yb0-x229.google.com ([2607:f8b0:4002:c09::229]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cYZpH-0003UN-Hy for pgadmin-hackers@postgresql.org; Tue, 31 Jan 2017 14:54:33 +0000 Received: by mail-yb0-x229.google.com with SMTP id o65so35239583ybo.2 for ; Tue, 31 Jan 2017 06:54:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pivotal-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fc6T6q2mT4Fr4fUEiuGou/9GD/PvtyMhm94o2vbWXCc=; b=k+H9gdqIHGX/fTbkwMiSzeZHlcfUwliier0z1i5xFEjyXWoPv2hRmUEzvK0ca1pKnN dpHll3/OLS44qbKydsG3iKpLVt5w0rf4jf9V9X3Iads5TZY0rPvpBnSOrj/8F2cLwGhg nZbSoziN16kjyaqRUbsEaMdlASA/tmf9s8bIzcTUe2MSONTibZLqPTJQzeyxaqvgBRCV u0tzNTnwrwXF1nrxPDOPV3yHqsAmrIbR05AyeT6UsvpuO24Y4imC039q/JQj3HcRkT4q q+dTWR0O8T9rHnmp7aCW/cAFyTHjV5EK6ahMxnq6/PHZiV6u0JEhUPBGRzhI0at8HgnI ZHHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fc6T6q2mT4Fr4fUEiuGou/9GD/PvtyMhm94o2vbWXCc=; b=FNHdo1j9qvJs1oSKrO35boX2MmILXMEKUCb5jAdYgJZvgYsSjb+M7Jo2VUEgnPMwhr 3KW1MRDMPpw8b3hH68i7NOPCy7qFoILYjY9ZqMWnsE7EpRMKoJ2urscOPrgFAPpiyAh/ 03+uz6B9tn/h0qjfnAYAd5EIzf9n9NooZcY8b3J/rUTf8yNoAyjZFwOzPlv4wG40R3vN Bx9ebq3kFiI/AJMa6Xohxwi4Gj99Yut9a+J6ZQnO7OvmTIlOPAdCre5CcMJLJxsvpp2H MGF4A3aKU9VjxV6k0Uz05GXbVbF7j4pkYgBz7i6wFt6ENRmdvPUbUv+TbUQKSviswK4Q VEsg== X-Gm-Message-State: AIkVDXJ+sr5ON/BWCb+HGPYlVSd6Grg+1iXwRglXHfBylGkDcChgFyHaT6GNNdE7yfCe4XQx9HXegtM8mvUHZPNl X-Received: by 10.37.104.73 with SMTP id d70mr15123820ybc.148.1485874468494; Tue, 31 Jan 2017 06:54:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.170.171 with HTTP; Tue, 31 Jan 2017 06:54:27 -0800 (PST) In-Reply-To: References: From: George Gelashvili Date: Tue, 31 Jan 2017 09:54:27 -0500 Message-ID: Subject: Re: Acceptance Tests against a browser (WIP) To: Dave Page Cc: Atira Odhner , pgadmin-hackers Content-Type: multipart/alternative; boundary=94eb2c14fceae07dba0547651b09 X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --94eb2c14fceae07dba0547651b09 Content-Type: text/plain; charset=UTF-8 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 wrote: > Hi > > On Mon, Jan 30, 2017 at 9:23 PM, Atira Odhner 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 > --94eb2c14fceae07dba0547651b09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,

We agree that a random port wo= uld 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 tha= t cleanup fails for whatever reason (e.g. a test errors out).=C2=A0 We see = this happen already with the randomized test databases you mention. We agre= e that there should probably be one strategy across the test suite. We coul= d use randomized names and have a more general cleanup step that removes al= l 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&= #39;s possible that the second error could be related to viewport size as y= ou suggested, but the first error just looks like a problem with the test n= ot being able to spin up its own server.

Thanks,
George & Tira

On Tue, Jan 31, 2017 at 9:41 AM, Dave Page <dpage@p= gadmin.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;
=C2=A0 =C2=A0 a) It should have detected that something else was running on= the port
=C2=A0 =C2=A0 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<= br> actually visible.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: runTest (pgadmin.acceptance.tests.connect_to_server_feature_test.ConnectsToServerFeatureTest)
-----------------------------------------------------------------= -----
Traceback (most recent call last):
=C2=A0 File "/Users/dpage/git/pgadmin4/web/pgadmin/accepta= nce/tests/connect_to_server_feature_test.py",
line 69, in tearDown
=C2=A0 =C2=A0 self.app_starter.stop_app()
=C2=A0 File "/Users/dpage/git/pgadmin4/web/regression/utils/app_<= wbr>starter.py",
line 27, in stop_app
=C2=A0 =C2=A0 os.killpg(os.getpgid(self.pgadmin_process.pid), signal.S= IGTERM)
OSError: [Errno 3] No such process

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: runTest (pgadmin.acceptance.tests.sql_template_selection_by_postgres_version_works_feature_test.SQLTemplateSelectionByPostg= resVersionWorksFeatureTest)
-----------------------------------------------------------------= -----
Traceback (most recent call last):
=C2=A0 File "/Users/dpage/git/pgadmin4/web/pgadmin/accepta= nce/tests/sql_template_selection_by_postgres_version_works_f= eature_test.py",
line 37, in runTest
=C2=A0 =C2=A0 self.page.find_by_xpath("//*[@id=3D'tree']/= /*[@class=3D'aciTreeText'
and .=3D'Trigger Functions']").click()
=C2=A0 File "/Users/dpage/git/pgadmin4/web/regression/utils/pgadm= in_page.py",
line 45, in find_by_xpath
=C2=A0 =C2=A0 return self.wait_for_element(lambda:
self.driver.find_element_by_xpath(xpath))
=C2=A0 File "/Users/dpage/git/pgadmin4/web/regression/utils/pgadm= in_page.py",
line 72, in wait_for_element
=C2=A0 =C2=A0 return self._wait_for("element to exist", element_i= f_it_exists)
=C2=A0 File "/Users/dpage/git/pgadmin4/web/regression/utils/pgadm= in_page.py",
line 106, in _wait_for
=C2=A0 =C2=A0 raise RuntimeError("timed out waiting for " + waiti= ng_for_message)
RuntimeError: timed out waiting for element to exist

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: runTest (pgadmin.acceptance.tests.sql_template_selection_by_postgres_version_works_feature_test.SQLTemplateSelectionByPostg= resVersionWorksFeatureTest)
-----------------------------------------------------------------= -----
Traceback (most recent call last):
=C2=A0 File "/Users/dpage/git/pgadmin4/web/pgadmin/accepta= nce/tests/sql_template_selection_by_postgres_version_works_f= eature_test.py",
line 60, in tearDown
=C2=A0 =C2=A0 self.page.find_by_xpath("//button[contains(.,'C= ancel')]").click()
=C2=A0 File "/Users/dpage/git/pgadmin4/web/regression/utils/pgadm= in_page.py",
line 45, in find_by_xpath
=C2=A0 =C2=A0 return self.wait_for_element(lambda:
self.driver.find_element_by_xpath(xpath))
=C2=A0 File "/Users/dpage/git/pgadmin4/web/regression/utils/pgadm= in_page.py",
line 72, in wait_for_element
=C2=A0 =C2=A0 return self._wait_for("element to exist", element_i= f_it_exists)
=C2=A0 File "/Users/dpage/git/pgadmin4/web/regression/utils/pgadm= in_page.py",
line 106, in _wait_for
=C2=A0 =C2=A0 raise RuntimeError("timed out waiting for " + waiti= ng_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

--94eb2c14fceae07dba0547651b09--