Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cdHkg-0000Ql-Pk for pgadmin-hackers@arkaria.postgresql.org; Mon, 13 Feb 2017 14:37:14 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cdHkg-0005a4-6B for pgadmin-hackers@arkaria.postgresql.org; Mon, 13 Feb 2017 14:37:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cdHkS-0005LI-8v for pgadmin-hackers@postgresql.org; Mon, 13 Feb 2017 14:37:00 +0000 Received: from mail-it0-x235.google.com ([2607:f8b0:4001:c0b::235]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cdHkK-0002rK-M7 for pgadmin-hackers@postgresql.org; Mon, 13 Feb 2017 14:36:59 +0000 Received: by mail-it0-x235.google.com with SMTP id c7so188463157itd.1 for ; Mon, 13 Feb 2017 06:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L18ypc1PZRIOnNnSgeihw3/C6mx/QVPya/j8RhgNnxc=; b=Vtg5QNbWjUhhhoa66/7MDpEMOJUP2PEGM7qmzCkFbYzx4DvPiuVmJOit+F03GCAMlU +M7NJTAaSs1Ks2sZkUjppA4wFRjUFriXZtgFGCrCVHU8KLRCmFl1UnzE1Fd91Q6ahHfI OZKRxTpNZOc+DhICvZnEKj7AurSbtbKlCPZ1I4Ydc9WYjI8aT0W2FPOnTH3Tn+dngUAR Gglj6zUDTR3HnA3RefK8adOM+IJ89dzlqIp/LSrfBvHgEUBglNkjiUO1Qu+a6VmsHb4B S0+Ev2FKs1lapBHbB39go72sdGv6txNgCCzGZE5gq6KMt4fnBhaWaUwjkjoXd3WEGRue JckA== 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=L18ypc1PZRIOnNnSgeihw3/C6mx/QVPya/j8RhgNnxc=; b=jmkqAeTDKSLqKU5BqhQqGga/WlUMqyVWkc31p87N4hckHHNHEFWwtrelh5d8b/uVz1 02EHOAz/Ti+BdNKUdabHEbbkPpew/ou1RpoQWJWamIPwEfMafIOC2ILBD+BJlkTW6vtu 1yv0JxBbXRZAp17D88jjkECIZx99XAUGrmFbIWO5Jekj2VhLgO49RfuA65TlQYYcTxVI M6crn4053cw73gHsjyP0JP89cRZOvFxp3rME8vHnb0JxtAXdd3Q4IK1DfL23d884r+33 t3KHueWYA29zw2j+meh8uL9iekZPlB4ZqddP9wrRGXjl6Mk4OnM+pkMAKps42s/MaPmB jJzA== X-Gm-Message-State: AMke39mKYe2BC6ihrst532yzuj9h+YHO7Q1HVhSq7aJxrPgV+4f035GYBulh3aRRswTuZN2CtcvL1pNq6okPBQ== X-Received: by 10.107.53.17 with SMTP id c17mr20205349ioa.45.1486996610829; Mon, 13 Feb 2017 06:36:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.224.198 with HTTP; Mon, 13 Feb 2017 06:36:49 -0800 (PST) In-Reply-To: References: From: Dave Page Date: Mon, 13 Feb 2017 14:36:49 +0000 Message-ID: Subject: Re: Acceptance Tests against a browser (WIP) To: Atira Odhner Cc: George Gelashvili , pgadmin-hackers Content-Type: text/plain; charset=UTF-8 X-Pg-Spam-Score: -2.6 (--) 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 Hi, I've been playing with this for the last couple of hours, and I just can't get it to work reliably; - A good percentage of the time the browser opens with a URL of "data:," and does nothing more. This appears to happen if tests fail, which still leaves server processes running in the background. - The connect_to_server test usually seems to work. - The template_selection_feature test usually does *not* work. I can't see an obvious reason, but I suspect it's a race condition. What seems to happen is that the function definition is entered, but not registered by the UI, so the mSQL panel just ends up saying "incomplete definition". Manually checking what was input proves that everything is correct - and indeed, returning the SQL tab shows the expected SQL. Other issues I noted: - The template_selection_feature test should just enter BEGIN/END. What it currently enters is an entire function definition, when only the body content is expected. E.g. self.page.fill_codemirror_area_with( """BEGIN END; """ ) - Screenshots are being taken of failed tests: 1) I've never actually seen any get saved 2) They should be saved to the same directory as the test log, not /tmp 3) They should have guaranteed unique names, and be mentioned in the test output so the user can reference the image to the failure. The reason the last two items are important is that I've now got a test server running the test suite with every supported version of Python, for every supported database (well, almost, pending a couple of fixes). I have separate workspaces for each Python version, and a single test run might run every test 10 times, once for each database server. - Please wrap the README at < 80 chars. On Thu, Feb 9, 2017 at 4:17 PM, Atira Odhner wrote: > Hi Dave, > >> I think the problem was that the way you phrased it, > > > You're right, we totally messed that up. We were talking about making 3 > patches and ended up making only 2 and forgot to reword that bit. > Sorry about that. > > Here are the two patches for this change that resolves the AttributeError > you were seeing. The first patch is identical to the patch of the same name > in the other email thread. > >> We're used to >> dealing with larger patchsets via the mailing list - typically as long >> as you're clear about any dependencies, it shouldn't be a problem. > > > Great! We'll try sending patchsets from now on and hopefully that resolves > some of the issues we were seeing. > > Tira & George > > On Thu, Feb 9, 2017 at 9:28 AM, Dave Page wrote: >> >> Hi >> >> On Thu, Feb 9, 2017 at 2:20 PM, Atira Odhner wrote: >> > Certainly. We did mention the dependency in the email. Would it be >> > better >> > to mention it in the patch name? >> >> I think the problem was that the way you phrased it, it sounded >> optional ("an updated patch which does not include adding that test >> helper in case you apply the show-tables patch first"). I think a >> clear "This patch is dependent on patch Foo" would suffice. >> >> > Is there a better way for us to manage >> > these changes? On other open source projects, I've seen github mirrors >> > set >> > up so that changes can be pulled in like branches rather then as patch >> > applies. That would have avoided this situation since the parent commit >> > would be pulled in with the same SHA from either pull request branch and >> > git >> > would not see it as a conflict. >> > >> > I'm rather new to dealing with patch files like this so I would love >> > some >> > tips. >> >> The Postgres project in general is quite conservative and stuck in >> it's ways about how things are done (which is usually a good thing >> considering you trust your data to the resulting code). We're used to >> dealing with larger patchsets via the mailing list - typically as long >> as you're clear about any dependencies, it shouldn't be a problem. >> Some of us use tools like PyCharms for handling patches and helping >> with reviews etc. which I guess replaces most, if not all of the >> GitHub functionality over plain git. >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> 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 (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers