March 2017 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQGRA-500) Navigation with URL parameters

by Vsevolod Golovanov (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-500?page=com.atlassian.jira.plugin... ] Vsevolod Golovanov commented on ARQGRA-500: ------------------------------------------- Then again, some parameter provider class wouldn't know the context to decide on parameters. Only the test does. Some location decider probably can get the current test instance and call some callback on it. The test just needs to implement the interface ParameterProvider - this would be the trigger. No need to alter the \@Location annotation. > Navigation with URL parameters > ------------------------------ > > Key: ARQGRA-500 > URL: https://issues.jboss.org/browse/ARQGRA-500 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Vsevolod Golovanov > > I need to add a dynamic URL parameter to a location of a page before navigating to it. > I don't want to use Selenium's navigation, because I would then need to reinvent/shoehorn Graphene's location deciding. > A special landing page would be a pretty ugly workaround. > I get that it's not possible with annotations. But at least support this with Graphene.goTo methods. > Actually it may be possible with annotations, if you could supply some provider class? E.g. {{\@Location(value = "MyView.xhtml", parameterProvider = MyParameterProvider.class)}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-500) Navigation with URL parameters

by Vsevolod Golovanov (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-500?page=com.atlassian.jira.plugin... ] Vsevolod Golovanov commented on ARQGRA-500: ------------------------------------------- Why won't I go via normal means like a user would, arrive to this parameterized page through other pages? Sometimes this path is too complex, the pages involved are too heavy - they have their own tests, other teams support those pages. Sometimes there may not be such a path at all, because some pages are linked directly with parameters by 3rd party applications. > Navigation with URL parameters > ------------------------------ > > Key: ARQGRA-500 > URL: https://issues.jboss.org/browse/ARQGRA-500 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Vsevolod Golovanov > > I need to add a dynamic URL parameter to a location of a page before navigating to it. > I don't want to use Selenium's navigation, because I would then need to reinvent/shoehorn Graphene's location deciding. > A special landing page would be a pretty ugly workaround. > I get that it's not possible with annotations. But at least support this with Graphene.goTo methods. > Actually it may be possible with annotations, if you could supply some provider class? E.g. {{\@Location(value = "MyView.xhtml", parameterProvider = MyParameterProvider.class)}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-500) Navigation with URL parameters

by Vsevolod Golovanov (JIRA)

Vsevolod Golovanov created ARQGRA-500: ----------------------------------------- Summary: Navigation with URL parameters Key: ARQGRA-500 URL: https://issues.jboss.org/browse/ARQGRA-500 Project: Arquillian Graphene Issue Type: Feature Request Reporter: Vsevolod Golovanov I need to add a dynamic URL parameter to a location of a page before navigating to it. I don't want to use Selenium's navigation, because I would then need to reinvent/shoehorn Graphene's location deciding. A special landing page would be a pretty ugly workaround. I get that it's not possible with annotations. But at least support this with Graphene.goTo methods. Actually it may be possible with annotations, if you could supply some provider class? E.g. {{\@Location(value = "MyView.xhtml", parameterProvider = MyParameterProvider.class)}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-484) Enriched element is not equal to the same element

by Vsevolod Golovanov (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-484?page=com.atlassian.jira.plugin... ] Vsevolod Golovanov commented on ARQGRA-484: ------------------------------------------- But sometimes a proxy doesn't implement WrapsElement, because it doesn't proxy a GrapheneElement, but a RemoteWebElement directly. E.g. {{driver.switchTo().activeElement()}}. This may be a separate bug... > Enriched element is not equal to the same element > ------------------------------------------------- > > Key: ARQGRA-484 > URL: https://issues.jboss.org/browse/ARQGRA-484 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.1.0.Alpha3 > Reporter: Jiří Štefek > > After upgrading to 2.1.0.Alpha3 from Alpha2, the following (simplified) test won't pass: > {code} > @FindBy(id="id") > private WebElement e; > @Test > private void test(){ > e.equals(e) > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-484) Enriched element is not equal to the same element

by Vsevolod Golovanov (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-484?page=com.atlassian.jira.plugin... ] Vsevolod Golovanov commented on ARQGRA-484: ------------------------------------------- {code:title=PR154}if (obj instanceof GrapheneElementImpl) { obj = ((GrapheneElementImpl) obj).element; } return element.equals(obj); {code} {{obj instanceof GrapheneElementImpl}} would most of the time evaluate to false because obj would be a proxy. So the execution would move on to {{element.equals(obj)}}, where it relies on Selenium's RemoteWebElement#equals to unwrap the obj (via the WrapsElement interface and its getWrappedElement() method). Might as well rely on it in case of {{obj instanceof GrapheneElementImpl}} evaluating to true. In fact, whenever there are proxies involved, code like {{otherObj.privateField}} seems iffy. What if a proxy sometimes extends the Impl class? > Enriched element is not equal to the same element > ------------------------------------------------- > > Key: ARQGRA-484 > URL: https://issues.jboss.org/browse/ARQGRA-484 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.1.0.Alpha3 > Reporter: Jiří Štefek > > After upgrading to 2.1.0.Alpha3 from Alpha2, the following (simplified) test won't pass: > {code} > @FindBy(id="id") > private WebElement e; > @Test > private void test(){ > e.equals(e) > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQ-2088) When test is skipped because of an assumption, Arquillian's test result is passed

by Matous Jobanek (JIRA)

Matous Jobanek created ARQ-2088: ----------------------------------- Summary: When test is skipped because of an assumption, Arquillian's test result is passed Key: ARQ-2088 URL: https://issues.jboss.org/browse/ARQ-2088 Project: Arquillian Issue Type: Enhancement Components: core Affects Versions: 1.1.13.Final Reporter: Matous Jobanek When you run Arquillian test with an assumption: {{Assume.assumeFalse(true);}} then the test is skipped. The same also say both IDE and maven surefire, but Arquillian's {{TestResult}} retrieved in {{After}} phase contains status Passed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1699) PhantomJS resolution by Spacelift

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/ARQ-1699?page=com.atlassian.jira.plugin.s... ] Matous Jobanek reassigned ARQ-1699: ----------------------------------- Assignee: Matous Jobanek > PhantomJS resolution by Spacelift > --------------------------------- > > Key: ARQ-1699 > URL: https://issues.jboss.org/browse/ARQ-1699 > Project: Arquillian > Issue Type: Task > Components: Extension - Drone > Reporter: Karel Piwko > Assignee: Matous Jobanek > Fix For: drone_2.1.0.Final > > > PhantomJS resolution should be done via Spacelift. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1699) PhantomJS resolution by Spacelift

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/ARQ-1699?page=com.atlassian.jira.plugin.s... ] Matous Jobanek updated ARQ-1699: -------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-extension-drone/pull/82 > PhantomJS resolution by Spacelift > --------------------------------- > > Key: ARQ-1699 > URL: https://issues.jboss.org/browse/ARQ-1699 > Project: Arquillian > Issue Type: Task > Components: Extension - Drone > Reporter: Karel Piwko > Fix For: drone_2.1.0.Final > > > PhantomJS resolution should be done via Spacelift. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1925) @After no longer runs within transaction boundaries since 1.1.7

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1925?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak commented on ARQ-1925: ------------------------------------- Upstream https://github.com/arquillian/arquillian-extension-transaction/commit/928... > @After no longer runs within transaction boundaries since 1.1.7 > --------------------------------------------------------------- > > Key: ARQ-1925 > URL: https://issues.jboss.org/browse/ARQ-1925 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Transaction > Affects Versions: transaction_1.0.1.Final, 1.1.7.Final > Reporter: Emond Papegaaij > Fix For: transaction_1.0.4 > > > With the changes in TestLifecycleEvents introduced in Arquillian core 1.1.7, the @After junit methods no longer run within the transaction boundaries. In TransactionHandler.endTransactionAfterTest, first the transaction is ended and then the event proceeds, calling @After methods. > I've created a pull request that switches these call, this fixes our testcases. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1925) @After no longer runs within transaction boundaries since 1.1.7

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1925?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak updated ARQ-1925: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > @After no longer runs within transaction boundaries since 1.1.7 > --------------------------------------------------------------- > > Key: ARQ-1925 > URL: https://issues.jboss.org/browse/ARQ-1925 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Transaction > Affects Versions: transaction_1.0.1.Final, 1.1.7.Final > Reporter: Emond Papegaaij > Fix For: transaction_1.0.4 > > > With the changes in TestLifecycleEvents introduced in Arquillian core 1.1.7, the @After junit methods no longer run within the transaction boundaries. In TransactionHandler.endTransactionAfterTest, first the transaction is ended and then the event proceeds, calling @After methods. > I've created a pull request that switches these call, this fixes our testcases. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues March 2017