September 2013 - arquillian-issues

[JBoss JIRA] (ARQGRA-375) Fail to relocate to @Location with named deployment

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-375?page=com.atlassian.jira.plugin... ] Juraj Húska updated ARQGRA-375: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/88 > Fail to relocate to @Location with named deployment > --------------------------------------------------- > > Key: ARQGRA-375 > URL: https://issues.jboss.org/browse/ARQGRA-375 > Project: Arquillian Graphene > Issue Type: Bug > Reporter: Lukáš Fryč > Assignee: Juraj Húska > Fix For: 2.0.0.Beta2 > > > The functional tests fail, so it's ignored for now: > https://github.com/arquillian/arquillian-graphene/blob/56a936e9206fe0cafd... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-375) Fail to relocate to @Location with named deployment

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-375?page=com.atlassian.jira.plugin... ] Work on ARQGRA-375 stopped by Juraj Húska. > Fail to relocate to @Location with named deployment > --------------------------------------------------- > > Key: ARQGRA-375 > URL: https://issues.jboss.org/browse/ARQGRA-375 > Project: Arquillian Graphene > Issue Type: Bug > Reporter: Lukáš Fryč > Assignee: Juraj Húska > Fix For: 2.0.0.Beta2 > > > The functional tests fail, so it's ignored for now: > https://github.com/arquillian/arquillian-graphene/blob/56a936e9206fe0cafd... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-377) Make Conditions API more concise when used for if statements and assertions

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-377?page=com.atlassian.jira.plugin... ] Juraj Húska updated ARQGRA-377: ------------------------------- Summary: Make Conditions API more concise when used for if statements and assertions (was: Improve the conditions API) > Make Conditions API more concise when used for if statements and assertions > --------------------------------------------------------------------------- > > Key: ARQGRA-377 > URL: https://issues.jboss.org/browse/ARQGRA-377 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.0.Beta1 > Reporter: Juraj Húska > > Currently the conditions API looks like: > {code} > new WebElementConditionFactory(webElement).isEnabled().apply(webDriverInstance);{code} > It should be improved to be more concise. > Consider inspiring with *hamcrest* library ([link|https://code.google.com/p/hamcrest/]), which should allow to have conditions API like: > {code} > import static foo.bar.Matchers.*; > public void testEquals() { > WebElement element = browser.findBy(By.tagName("body")); > assertThat(element, isDisplayed()); > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-377) Improve the conditions API

by Marek Schmidt (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-377?page=com.atlassian.jira.plugin... ] Marek Schmidt commented on ARQGRA-377: -------------------------------------- We can maybe also just have e.g. condition() to "realize" the fluidum: if (condition().element(webElementOrBy).is().not().present()) { ... } so one piece of the same code can be used in both waits and conditions, which I believe is the core of this usability issue. > Improve the conditions API > -------------------------- > > Key: ARQGRA-377 > URL: https://issues.jboss.org/browse/ARQGRA-377 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.0.Beta1 > Reporter: Juraj Húska > > Currently the conditions API looks like: > {code} > new WebElementConditionFactory(webElement).isEnabled().apply(webDriverInstance);{code} > It should be improved to be more concise. > Consider inspiring with *hamcrest* library ([link|https://code.google.com/p/hamcrest/]), which should allow to have conditions API like: > {code} > import static foo.bar.Matchers.*; > public void testEquals() { > WebElement element = browser.findBy(By.tagName("body")); > assertThat(element, isDisplayed()); > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-377) Improve the conditions API

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-377?page=com.atlassian.jira.plugin... ] Lukáš Fryč commented on ARQGRA-377: ----------------------------------- Few points: 1. for determining whether an element is enabled, you should use the simplest API possible: {code} WebElement#isEnabled() {code} http://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/WebE... 2. (y) +1 for being able to build assertions and waiting conditions in unified manner (if statements doesn't apply afaik) ---- 3. we could leverage interceptors to wrap instances and wait on conditions specified in closing word (method), e.g.: {code} element.isEnabled(); waitGui().until().element(element).isEnabled(); assertThat(element, isEnabled()); {code} the problem is that {{WebElement#isEnabled}} returns false, but it should return {{FluentBase<?>}} otherwise. One of the solutions comes from extending capabilities of {{WebElement}} interface and transform it to fluent API, consumed later by e.g. {{GrapheneElement}}. Say we have interface: {code} public interface ElementOperation<B, T> { B isEnabled(); T getText(); ... } {code} then we can: {code} public class GrapheneElement implements WebElement, ElementOperation<Boolean, String> { Boolean isEnabled(); String getText(); ... } {code} Based on a returned type, you could leverage that same API in assetions/waiting conditions: {code} public class FluentElement implements ElementOperation<FluentBoolean, FluentString> { FluentBoolean isEnabled(); FluentString getText(); } {code} ---- Do you have another ideas? I think re-implementation is not possible at this stage, as we are approaching 2.0 Final release. I would rather take it as suggestions for improvement in 3.0 or alternative API in 2.Future. > Improve the conditions API > -------------------------- > > Key: ARQGRA-377 > URL: https://issues.jboss.org/browse/ARQGRA-377 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.0.Beta1 > Reporter: Juraj Húska > > Currently the conditions API looks like: > {code} > new WebElementConditionFactory(webElement).isEnabled().apply(webDriverInstance);{code} > It should be improved to be more concise. > Consider inspiring with *hamcrest* library ([link|https://code.google.com/p/hamcrest/]), which should allow to have conditions API like: > {code} > import static foo.bar.Matchers.*; > public void testEquals() { > WebElement element = browser.findBy(By.tagName("body")); > assertThat(element, isDisplayed()); > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-79) Migrate command interceptors to Selenium 2

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-79?page=com.atlassian.jira.plugin.... ] Lukáš Fryč edited comment on ARQGRA-79 at 9/16/13 5:48 AM: ----------------------------------------------------------- There is base for type-safe definitions of interceptors (InterceptorBuilder): https://github.com/arquillian/arquillian-graphene/commit/7cf0bad4a4a219f6... This concept needs to be further tested and then adopted internally by Graphene. was (Author: lfryc): There is base for type-safe definitions of interceptors (InterceptorBuilder): https://github.com/arquillian/arquillian-graphene/commit/7cf0bad4a4a219f6... This concept needs to be further tested and then adopter internally by Graphene. > Migrate command interceptors to Selenium 2 > ------------------------------------------ > > Key: ARQGRA-79 > URL: https://issues.jboss.org/browse/ARQGRA-79 > Project: Arquillian Graphene > Issue Type: Epic > Components: api, core > Reporter: Lukáš Fryč > Priority: Optional > Fix For: 2.1-Tracking > > > There is listener capability in Selenium 2, it could by used in place of interceptors from Ajocado 1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-79) Migrate command interceptors to Selenium 2

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-79?page=com.atlassian.jira.plugin.... ] Lukáš Fryč edited comment on ARQGRA-79 at 9/16/13 5:48 AM: ----------------------------------------------------------- There is base for type-safe definitions of interceptors (InterceptorBuilder): https://github.com/arquillian/arquillian-graphene/commit/7cf0bad4a4a219f6... This concept needs to be further tested and then adopter internally by Graphene. was (Author: lfryc): There is base for type-safe definitions of interceptors (InterceptorBuilder): https://github.com/arquillian/arquillian-graphene/commit/7cf0bad4a4a219f6... This concept needs to be further tested and optimally used internally by Graphene. > Migrate command interceptors to Selenium 2 > ------------------------------------------ > > Key: ARQGRA-79 > URL: https://issues.jboss.org/browse/ARQGRA-79 > Project: Arquillian Graphene > Issue Type: Epic > Components: api, core > Reporter: Lukáš Fryč > Priority: Optional > Fix For: 2.1-Tracking > > > There is listener capability in Selenium 2, it could by used in place of interceptors from Ajocado 1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-377) Improve the conditions API

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-377?page=com.atlassian.jira.plugin... ] Karel Piwko commented on ARQGRA-377: ------------------------------------ We need to have conditions/predicates supported in all assert, assume and if() statement. So, hamcrest matchers solve problem only partly, because I assume you can't use them in if() statements. That said, I think that hamcrest matchers represent a great addition to JUnit. There also http://code.google.com/p/selenium/wiki/LiftStyleApi, which is trying to improve writing conditions for WebDriver. > Improve the conditions API > -------------------------- > > Key: ARQGRA-377 > URL: https://issues.jboss.org/browse/ARQGRA-377 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.0.Beta1 > Reporter: Juraj Húska > > Currently the conditions API looks like: > {code} > new WebElementConditionFactory(webElement).isEnabled().apply(webDriverInstance);{code} > It should be improved to be more concise. > Consider inspiring with *hamcrest* library ([link|https://code.google.com/p/hamcrest/]), which should allow to have conditions API like: > {code} > import static foo.bar.Matchers.*; > public void testEquals() { > WebElement element = browser.findBy(By.tagName("body")); > assertThat(element, isDisplayed()); > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-377) Improve the conditions API

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-377?page=com.atlassian.jira.plugin... ] Karel Piwko updated ARQGRA-377: ------------------------------- Description: Currently the conditions API looks like: {code} new WebElementConditionFactory(webElement).isEnabled().apply(webDriverInstance);{code} It should be improved to be more concise. Consider inspiring with *hamcrest* library ([link|https://code.google.com/p/hamcrest/]), which should allow to have conditions API like: {code} import static foo.bar.Matchers.*; public void testEquals() { WebElement element = browser.findBy(By.tagName("body")); assertThat(element, isDisplayed()); } {code} was: Currently the conditions API looks like: {code} new WebElementConditionFactory(webElement).isEnabled().apply(webDriverInstance);{code} It should be improved to be more concise. Consider inspiring with *hamcrest* library ([link|https://code.google.com/p/hamcrest/]), which should allow to have conditions API like: {code} import foo.bar.Matchers.*; public void testEquals() { WebElement element = browser.findBy(By.tagName("body")); assertThat(element, isDisplayed()); } {code} > Improve the conditions API > -------------------------- > > Key: ARQGRA-377 > URL: https://issues.jboss.org/browse/ARQGRA-377 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.0.Beta1 > Reporter: Juraj Húska > > Currently the conditions API looks like: > {code} > new WebElementConditionFactory(webElement).isEnabled().apply(webDriverInstance);{code} > It should be improved to be more concise. > Consider inspiring with *hamcrest* library ([link|https://code.google.com/p/hamcrest/]), which should allow to have conditions API like: > {code} > import static foo.bar.Matchers.*; > public void testEquals() { > WebElement element = browser.findBy(By.tagName("body")); > assertThat(element, isDisplayed()); > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-375) Fail to relocate to @Location with named deployment

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-375?page=com.atlassian.jira.plugin... ] Work on ARQGRA-375 started by Juraj Húska. > Fail to relocate to @Location with named deployment > --------------------------------------------------- > > Key: ARQGRA-375 > URL: https://issues.jboss.org/browse/ARQGRA-375 > Project: Arquillian Graphene > Issue Type: Bug > Reporter: Lukáš Fryč > Assignee: Juraj Húska > Fix For: 2.0.0.Beta2 > > > The functional tests fail, so it's ignored for now: > https://github.com/arquillian/arquillian-graphene/blob/56a936e9206fe0cafd... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues September 2013