[TIP] page_objects: page object definitions behaving unexpectedly

Nicholas Mellor Nicholas.Mellor at medibank.com.au
Mon Nov 14 18:04:33 PST 2016


Hey all,

First post here. I'm not new to Selenium, but fairly rusty using Python for Selenium testing.

I'm using the page_objects 1.1 library on Python 3.4.3.

Here's my code:

def binary_choice(agree=None, disagree=None):
    q = {}
    if agree:
        q.update(dict(agree=PageElement(css=agree)))
    if disagree:
        q.update(dict(disagree=PageElement(css=disagree)))
    return q

class BackCareRiskAssessmentQuestionnairePage(PageObject):
    # My back pain has spread down my leg(s) at some time in the last 2 weeks
    spread_down_legs_disagree = PageElement(id_="form-riskForm-legPain-1")
    spread_down_legs = binary_choice(disagree= 'form-riskForm-legPain-1')

Can someone explain why:

page.spread_down_legs['disagree'] is of type PageElement and can't be clicked

whereas:

page.spread_down_legs_disagree is of type WebElement and is clickable?

I think it must be something to do with class definition time as opposed to execution time, but I can't quite figure out what Python's doing or why.

Thanks!

Nick

-----Original Message-----
From: testing-in-python-bounces at lists.idyll.org [mailto:testing-in-python-bounces at lists.idyll.org] On Behalf Of testing-in-python-request at lists.idyll.org
Sent: Tuesday, 15 November 2016 7:00 AM
To: testing-in-python at lists.idyll.org
Subject: testing-in-python Digest, Vol 118, Issue 9

Send testing-in-python mailing list submissions to
	testing-in-python at lists.idyll.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.idyll.org/listinfo/testing-in-python
or, via email, send a message with subject or body 'help' to
	testing-in-python-request at lists.idyll.org

You can reach the person managing the list at
	testing-in-python-owner at lists.idyll.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of testing-in-python digest..."


Today's Topics:

   1. Re: CTracer vs PyTracer in coverage.py 4.2; different
      behavior/caching? (Ned Batchelder)


----------------------------------------------------------------------

Message: 1
Date: Sun, 13 Nov 2016 20:41:03 -0500
From: Ned Batchelder <ned at nedbatchelder.com>
Subject: Re: [TIP] CTracer vs PyTracer in coverage.py 4.2; different
	behavior/caching?
To: testing-in-python at lists.idyll.org
Message-ID: <154c61c4-11ac-9181-b77f-c402365011a3 at nedbatchelder.com>
Content-Type: text/plain; charset="windows-1252"

Robert, this sounds involved and specific, so let's take it off-list.

--Ned.


On 11/13/16 2:14 AM, R M Waters wrote:
> Hi,
>
> I am attempting to run individual coverage reports for tests in a 
> large suite in order to run some analysis on the suite.  I am using 
> nose as the test runner, and executing the `erase()` and `start()` 
> methods of `coverage.Coverage` between each test invocation in order 
> to reset the coverage data.
>
> Some of our test methods follow the same branch pattern, but with 
> different data (consider testing an encode/decode function with 
> varying inputs).
>
> Using PyTracer, I can retrieve the coverage data for each test via 
> `collector.data`.  This includes tests that have the same branch 
> pattern (it will return same coverage data for those tests).
>
> However, using CTracer, I can retrieve coverage data only for the 
> first invocation of a particular branch pattern.  Subsequent 
> invocations return an empty dict.
>
> I have even tried replacing the entire `coverage.Coverage` object for 
> each test, which should guarantee that all of the data and trace cache 
> on the python side are purged, no dice though. Is CTracer a singleton?
>
> I can understand if this is an optimization; when running a coverage 
> report for a test suite, this is all useless data.
>
> Is this expected behavior?  Am I going to have to go out of process, 
> or is there an easier solution?
>
> Thank you so much,
> Robert Waters
>
>
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20161113/935d30a3/attachment-0001.htm>

------------------------------

_______________________________________________
testing-in-python mailing list
testing-in-python at lists.idyll.org
http://lists.idyll.org/listinfo/testing-in-python


End of testing-in-python Digest, Vol 118, Issue 9
*************************************************

Email Scanned by MessageLabs

The information contained in or attached to this message is intended only for the people it is addressed to. If you are not the intended recipient, please notify the sender and delete the email. Any use, disclosure or copying of this information is unauthorised and prohibited.This information may be confidential or subject to legal privilege. It is not the expressed view of Medibank Private Limited (ABN 47 080 890 259) or any of its subsidiaries (together 'Medibank') unless it is authorised by a person with actual authority. To the fullest extent allowed by law, Medibank does not accept liability for any damage caused by this message, including any virus damage.



More information about the testing-in-python mailing list