Why do you need the WebElementFacade?

[Alex Okrushko]

Hey John and everyone else,

As I'm getting deeper into Thucydides I start having some questions:

Why do we need the WebElementFacade at all?

I mean I get the added functionality to the WebElement (and I love it), however I why is it implemented this way:

@FindBy(css = "input[name='username']")

private WebElement username;

public void login(String username){

    element(this.username).type(username)

}

instead of:

@FindBy(css = "input[name='username']")

private WebElementFacade username;

public void login(String username){

     this.username.type(username)

}

I think it's time to change it :)

Before I jump in, I just want to clarify if there is a particular idea behind current implementation?

Also, with the current implementation each WebElement is "Proxied" twice: (please correct my if I'm wrong)

- once in PageFactory

- second time during initWebElementFacades() of WebDriverFactory.

Thanks,

Alex

[Mike W]

The WebElementFacade is required because WebElement is actually from WebDriver, and not under Thucydides control. 

Being able to use WebElementFacade directly in a test is a relatively new thing for Thucydides. It was added in 0.9.103. So, now you can use WebElementFacade fields in your tests and not have to call element() everywhere. Obviously John thought the same thing as you ;)

I haven't looked, but would also assume that PageFactory will instantiate WebElement's, and initWebElementFacades would only be instantiating WebElementFacades.

[Alex Okrushko]

Thanks Mike, John has already replied to me and I've done some more digging. :)

Actually I'd like to extend that and we had a discussion:

me:

I like the added functionality of WebElementFacade, however I'd like to make it extensible (through Decorator)

Currently I add my own functionality to to native WebElement objects and it works fine. However I'd like to add the WebElementFacade's functionality as well. :)

For that WebElementFacade would have to become an interface and my Decorator would have to be thrown in.

Once that is done and anybody would be able to extend the interface WebElementFacade and the WebElementFacadeImpl class that implements it and create their's own classes that still would be proxied and discovered by FindBy.

What do you think?

I can added it quite easily and it would be working, however I'm afraid that a ton of your unit tests would be broken again.

Do you want me to work on it? Do you see it going into the Thucydides? (I might need help with the unit tests though)

John:

Sounds like a good idea - changing to an interface shouldn't break many tests - initially you would just rename WebElementFacade to WebElementFacadeImpl or DefaultWebElementFacade (or something like that), then create and test the interface.

So hope we can see extensible WebElements/WebElementFacades in Thucydides :)

Alex 

--
You received this message because you are subscribed to the Google Groups "Thucydides Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thucydides-use...@googlegroups.com.
To post to this group, send an email to thucydid...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Mike Wilkes]

I thought John may have replied already, but just in case... I'm finding the Google Groups ui is not intuitive, unless he intentionally meant to respond to you only. 

It appears that if you click the left pointing area directly, it responds to the group. If you choose the dropdown, it replies only to that individual. Wasn't obvious to me that's what it was doing.

Look forward to custom, extensible WebElements.

[Alex Okrushko]

Hey Mike,

Maybe a bit off-topic, but do you have any problems with poms? Specifically with 

 <plugin>

                <groupId>org.codehaus.gmaven</groupId>

                <artifactId>gmaven-plugin</artifactId>

                <version>1.3</version>

                <configuration>

                    <providerSelection>1.7</providerSelection>

                </configuration>

                <executions>

                    <execution>

                        <goals>

                            <goal>compile</goal>

                            <goal>testCompile</goal>

                        </goals>

                    </execution>

                </executions>

            </plugin>

I get the error Plugin execution not covered by lifecycle configuration: org.codehaus.gmaven:gmaven-plugin:1.3:testCompile (execution: default, phase: test-compile)

and I've been fighting it for quite some time - still cannot figure it out.

[Mike W]

I assume you're experiencing this in Eclipse. If so, then yes, I've seen this issue. IDEA appears to have this managed in either a Groovy or a Maven plugin, so I don't experience it there, and that's where I do most of my development these days...

Tried to find an appropriate plugin for Eclipse to address that, but didn't have any luck. Let me know if you have better luck.

.

[John Smart]

Hi guys,

Briefly: we need groovy in the build as all the newer tests are written in Spock. That's what GMaven is about. I've had good results with the Groovy Eclipse plugin recently, though, so we could try switching to that to see if it makes things easier for Eclipse/Windows configs. The Spring version of Eclipse seems to be better than most flavors for Groovy support, but I've always found Groovy support in Eclipse a bit dodgy. Have you tried mvn eclipse:eclipse?

I develop on a Mac in IntelliJ, so I don't see a lot of the Windows issues first-hand (I run the build in a VM from time to time, or to isolate issues). We have noticed issues with spaces in the path names on Windows, as some of the tests for uploading files don't cater for paths with spaces in them very well. Running the build in a project path without spaces (e.g. C:\Projects\thucydides) will get around this. 

- John

--
___________________________________________________
John Smart | Wakaleo Consulting  |  +61 407 247 642
Optimizing your software development process
http://www.wakaleo.com  |  john....@wakaleo.com

[Alex Okrushko]

Hey John,

Yep, I'm at Windows Spring Tool Suite 3.1 with Java 1.6 which might make things more complicated for me.

John, do you have jenkins running your unit test? If yes, do you have anonymous public access? Which browsers/platforms/jdks do you run your unit tests against?

Thanks,

Alex

[John Smart]

Yes, there is a jenkins instance, but I'm redoing it at the moment to use the new release process (which is gradle-based). I'll post the link here when it is all ready to go, as since there is an increasing number of people working on the code base, it would be good to get the notifications out to everyone interested.

[Mike W]

I'm currently working on Windows, switched to jdk1.6 for Thucydides development (to ensure I don't introduce anymore 1.7 specific changes) and use Intellij.

Definitely add me to the list for the Jenkins build reports.

[Alex Okrushko]

Hey Mike,

extensible WebElementFacade is now done. Waiting on John to review :)

https://github.com/alex-okrushko/thucydides/commit/2655031c5ae5f4710c358050806cba269410c675

On Friday, March 22, 2013 9:38:28 AM UTC-4, Mike W wrote:

[John Smart]

Hmmm, not working here yet....

  should be able to configure default listeners(net.thucydides.core.WhenSettingUpReportServices): Injector has not been initialized yet

  should be able to configure default listeners with a webdriver instance(net.thucydides.core.WhenSettingUpReportServices): Injector has not been initialized yet

  should be able to obtain the results from the base step listener(net.thucydides.core.WhenSettingUpReportServices): Injector has not been initialized yet

Tests run: 1795, Failures: 0, Errors: 919, Skipped: 3

[INFO] ------------------------------------------------------------------------

[INFO] Reactor Summary:

[INFO]

[INFO] thucydides ........................................ SUCCESS [2.017s]

[INFO] thucydides-test-utils ............................. SUCCESS [3.236s]

[INFO] thucydides-report-resources ....................... SUCCESS [1.593s]

[INFO] thucydides-sample-alternative-resources ........... SUCCESS [1.617s]

[INFO] thucydides-core ................................... FAILURE [32.839s]

[INFO] thucydides-junit .................................. SKIPPED

[INFO] Thucydides Maven Plugin ........................... SKIPPED

[INFO] Thucydides Easyb Plugin ........................... SKIPPED

[INFO] ------------------------------------------------------------------------

[INFO] BUILD FAILURE

[INFO] ------------------------------------------------------------------------

Have you tried building locally in C:/Projects/thucydides? Also, make sure you merge in the latest changes from master so that the pull request can be merged smoothly.

- John.

[Alex Okrushko]

Hey John,

this message " Injector has not been initialized yet" has been removed at this commit, which is about 15-20 commit ago, so you probably still have the old version. 

Also, I've got all the merges from the master :) (you can check here). Well, almost all  - I'm missing https://github.com/thucydides-webtests/thucydides/pull/75 because it was done 23 minutes ago :)

Alex

[John Smart]

Cool - when you merge the changes into master, you should be able to get the 'Merge automatically' button appearing on the github screen. If it isn't there, it means there are still conflicts.

[Alex Okrushko]

I'm not sure what you mean by this - I use eclipse with git plug-in.

My 'origin\master' is my fork of thucydides https://github.com/alex-okrushko/thucydides

My remote 'upstream\master' is your https://github.com/thucydides-webtests/thucydides

I do pull from 'upstream\master' once in a while - to make you that mine is in sync.

Have you had any success with my latest commit? all the tests should pass.

[John Smart]

Hi Alex,

I just checked directly against your repo. I'm just getting the following unit test error:

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

Test set: net.thucydides.core.webdriver.WhenChoosingAnElementLocatorFactory

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

Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.034 sec <<< FAILURE!

should choose the DisplayedElementLocatorFactory factory by default(net.thucydides.core.webdriver.WhenChoosingAnElementLocatorFactory)  Time elapsed: 0.023 sec  <<< FAILURE!

Condition not satisfied:

locator.class == DisplayedElementLocatorFactory

|       |     |

|       |     false

|       class net.thucydides.core.webdriver.smart.SmartElementLocatorFactory

net.thucydides.core.webdriver.smart.SmartElementLocatorFactory@46a53f5a

at net.thucydides.core.webdriver.WhenChoosingAnElementLocatorFactory.should choose the DisplayedElementLocatorFactory factory by default(WhenChoosingAnElementLocatorFactory.groovy:22)

                                                                                                   

So looks like that test just needs updating. The integration tests get run after that phase, so I didn't see if they are running.

[Alex Okrushko]

Hey John,

This test is probably not part of junit tests of thucydides-core. Is it groovy? I haven't worked with it yet and gmaven is giving me troubles :-(

[John Smart]

You should be able to run them from the command line - yes, it's a Spock test. It would probably be worth spending some time getting Spock/Groovy set up correctly in your Eclipse environment (a pain, I know), as Spock is how almost all the new unit tests will be written.