[JBoss JIRA] (ARQGRA-472) TestCases are copy-pasted
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-472?page=com.atlassian.jira.plugin... ]
Lukáš Fryč updated ARQGRA-472:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/151
> TestCases are copy-pasted
> -------------------------
>
> Key: ARQGRA-472
> URL: https://issues.jboss.org/browse/ARQGRA-472
> Project: Arquillian Graphene
> Issue Type: Bug
> Components: unit-test
> Affects Versions: 2.1-Tracking
> Reporter: Vitalii Grygoryuk
> Assignee: Matous Jobanek
> Fix For: 2.1-Tracking
>
>
> TestHandlingOfStaleElements.testDeletion() and TestHandlingOfStaleElements.testReplacement() are both testing deletion, so there is no test case for node replacement logic:
> {code}
> @Test
> public void testDeletion() {
> rootElement.isDisplayed();
> executor.executeScript("return arguments[0].parentNode.removeChild(arguments[0])", rootElement);
> try {
> rootElement.isDisplayed();
> fail("rootElement should not be found");
> } catch (NoSuchElementException e) {
> }
> }
> @Test
> public void testReplacement() {
> rootElement.isDisplayed();
> executor.executeScript("return arguments[0].parentNode.removeChild(arguments[0])", rootElement);
> try {
> rootElement.isDisplayed();
> fail("rootElement should not be found");
> } catch (NoSuchElementException e) {
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (ARQGRA-483) @Location might use the Wrong URL when used with Warp
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-483?page=com.atlassian.jira.plugin... ]
Lukáš Fryč updated ARQGRA-483:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/153
> @Location might use the Wrong URL when used with Warp
> ------------------------------------------------------
>
> Key: ARQGRA-483
> URL: https://issues.jboss.org/browse/ARQGRA-483
> Project: Arquillian Graphene
> Issue Type: Bug
> Components: integration
> Affects Versions: 2.1.0.Alpha2
> Reporter: Aslak Knutsen
> Fix For: 2.1-Tracking
>
>
> Both Graphene and Warp attempt to override the default Core URLResourceProvider.
> Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider.
> When both Graphene and Warp is on classpath it becomes unpredictable who will actually win.
> Technically the two URLs used here could be different:
> {code}
> @ArquillianResource
> private URL baseURL;
>
> @Test @RunAsClient
> public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception {
> }
> {code}
> BaseURL could be proxied and the URL used by InitialPage not, or the other way around.
> Graphene sets up it's ContextRootStore with which ever URL was provided last;
> https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/ma...
> Core will do the opposite, which ever comes first.
> When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync.
> This seems to be a good test case currently:
> {code}
> @Drone
> private WebDriver driver;
>
> @ArquillianResource
> private URL baseURL;
>
> @Test @RunAsClient
> public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception {
> Assert.assertEquals(baseURL.getPort(), new URL(driver.getCurrentUrl()).getPort());
> }
> {code}
> Currently one will show 'proxy-port' and the other '8080'.
> This has to do with the dependency order. If you place Graphene before Warp in the POM then Graphene will work because Warp's ProxyURLProvider is the last provider, if you place Warp before Graphene you should see this issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (ARQ-2016) Improve the ability to add custom extensions for the containers
by Steve Storck (JIRA)
[ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.s... ]
Steve Storck updated ARQ-2016:
------------------------------
Summary: Improve the ability to add custom extensions for the containers (was: arquillian-osgi-bundle includes dependencies but does not export them)
> Improve the ability to add custom extensions for the containers
> ---------------------------------------------------------------
>
> Key: ARQ-2016
> URL: https://issues.jboss.org/browse/ARQ-2016
> Project: Arquillian
> Issue Type: Feature Request
> Components: OSGi Containers
> Affects Versions: osgi_2.1.0.Final
> Environment: Under Linux, and inside Karaf 4.x
> Reporter: Steve Storck
>
> When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows:
> {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid}
> package org.jboss.arquillian.spock;
> public class ArquillianSputnik extends Sputnik {
> import org.jboss.arquillian.test.spi.TestRunnerAdaptor;
> import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder;
> // Methods and fields omitted for brevity, but you can see that the
> // proper packages are imported
> public void run(RunNotifier notifier) {
> // Code omitted for brevity
> final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build();
> // More code omitted for brevity
> }
> }
> {code}
> {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid}
> package org.jboss.arquillian.test.spi;
> public class TestRunnerAdaptorBuilder {
> private static final String DEFAULT_EXTENSION_CLASS =
> "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader";
> private static final String TEST_RUNNER_IMPL_CLASS =
> "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor";
> public static TestRunnerAdaptor build() {
> // omitted lines for brevity
> ManagerBuilder builder = ManagerBuilder.from()
> .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS));
> return SecurityActions.newInstance(
> TEST_RUNNER_IMPL_CLASS,
> new Class<?>[] {ManagerBuilder.class},
> new Object[] {builder},
> TestRunnerAdaptor.class);
> }
> }
> {code}
> {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid}
> package org.jboss.arquillian.test.spi;
> final class SecurityActions {
> static <T> T newInstance(final String className,
> final Class<?>[] argumentTypes,
> final Object[] arguments,
> final Class<T> expectedType) {
> @SuppressWarnings("unchecked")
> Class<T> implClass = (Class<T>) loadClass(className);
> if (!expectedType.isAssignableFrom(implClass)) {
> throw new RuntimeException("Loaded class " +
> className +
> " is not of expected type " +
> expectedType);
> }
> return newInstance(implClass, argumentTypes, arguments);
> }
> }
> {code}
> I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own.
> Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (ARQ-2001) Log status code in WLPRestClient.isServerUp()
by Gerhard Poul (JIRA)
[ https://issues.jboss.org/browse/ARQ-2001?page=com.atlassian.jira.plugin.s... ]
Gerhard Poul updated ARQ-2001:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Log status code in WLPRestClient.isServerUp()
> ---------------------------------------------
>
> Key: ARQ-2001
> URL: https://issues.jboss.org/browse/ARQ-2001
> Project: Arquillian
> Issue Type: Enhancement
> Components: WebSphere Containers
> Reporter: Paul Holding
> Assignee: Gerhard Poul
> Fix For: was_1.0.0.next
>
>
> The WLPRestClient.isServerUp() method doesn't log the status code returned when the following line of code is executed
> {code:java}
> HttpResponse result = executor.execute(Request.Get(hostName)).returnResponse();
> {code}
> The lack of logging makes is impossible to tell why the isServerUp() check failure occurred and the only information returned is a LifecycleException thrown by WLPRemoteContainer with the text "Remote server is not started". This can be misleading as the server may be up but something else is wrong such as an authentication failure.
> Adding something similar to the logging in WLPRestClient.deploy(File archive) would allow the HTTP status code to be recorded and make troubleshooting a lot easier.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (ARQ-2001) Log status code in WLPRestClient.isServerUp()
by Gerhard Poul (JIRA)
[ https://issues.jboss.org/browse/ARQ-2001?page=com.atlassian.jira.plugin.s... ]
Gerhard Poul updated ARQ-2001:
------------------------------
Fix Version/s: was_1.0.0.next
> Log status code in WLPRestClient.isServerUp()
> ---------------------------------------------
>
> Key: ARQ-2001
> URL: https://issues.jboss.org/browse/ARQ-2001
> Project: Arquillian
> Issue Type: Enhancement
> Components: WebSphere Containers
> Reporter: Paul Holding
> Assignee: Gerhard Poul
> Fix For: was_1.0.0.next
>
>
> The WLPRestClient.isServerUp() method doesn't log the status code returned when the following line of code is executed
> {code:java}
> HttpResponse result = executor.execute(Request.Get(hostName)).returnResponse();
> {code}
> The lack of logging makes is impossible to tell why the isServerUp() check failure occurred and the only information returned is a LifecycleException thrown by WLPRemoteContainer with the text "Remote server is not started". This can be misleading as the server may be up but something else is wrong such as an authentication failure.
> Adding something similar to the logging in WLPRestClient.deploy(File archive) would allow the HTTP status code to be recorded and make troubleshooting a lot easier.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months