[JBoss JIRA] (ARQ-1818) JUnit @Before/After phase is called after/before Arquillian's Before/After phase
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/ARQ-1818?page=com.atlassian.jira.plugin.s... ]
Aslak Knutsen updated ARQ-1818:
-------------------------------
Affects Version/s: 1.1.6.Final
> JUnit @Before/After phase is called after/before Arquillian's Before/After phase
> --------------------------------------------------------------------------------
>
> Key: ARQ-1818
> URL: https://issues.jboss.org/browse/ARQ-1818
> Project: Arquillian
> Issue Type: Bug
> Components: Test Harness Integration
> Affects Versions: 1.1.5.Final, 1.1.6.Final
> Reporter: Aslak Knutsen
> Assignee: Aslak Knutsen
> Priority: Blocker
> Fix For: 1.1.7.Final
>
>
> In < 1.1.5.Final JUnit's @Before and @After was called by Arquillian as part of Arquillian's Before and After phases. This changed by accident during the JUnit Rule support rewrite and @Before is now called after Arquillian's Before and @After phase is now called Before Arquillian's After.
> This break down APIs like Deployer/ContainerController as non of the Suite/Class/Test Contexts are active at that point.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (ARQ-1818) JUnit @Before/After phase is called after/before Arquillian's Before/After phase
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/ARQ-1818?page=com.atlassian.jira.plugin.s... ]
Aslak Knutsen updated ARQ-1818:
-------------------------------
Fix Version/s: 1.1.7.Final
(was: 1.1.6.Final)
> JUnit @Before/After phase is called after/before Arquillian's Before/After phase
> --------------------------------------------------------------------------------
>
> Key: ARQ-1818
> URL: https://issues.jboss.org/browse/ARQ-1818
> Project: Arquillian
> Issue Type: Bug
> Components: Test Harness Integration
> Affects Versions: 1.1.5.Final, 1.1.6.Final
> Reporter: Aslak Knutsen
> Assignee: Aslak Knutsen
> Priority: Blocker
> Fix For: 1.1.7.Final
>
>
> In < 1.1.5.Final JUnit's @Before and @After was called by Arquillian as part of Arquillian's Before and After phases. This changed by accident during the JUnit Rule support rewrite and @Before is now called after Arquillian's Before and @After phase is now called Before Arquillian's After.
> This break down APIs like Deployer/ContainerController as non of the Suite/Class/Test Contexts are active at that point.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (ARQ-1902) Provide SPI for conditional execution of test methods
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/ARQ-1902?page=com.atlassian.jira.plugin.s... ]
Aslak Knutsen updated ARQ-1902:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
pushed upstream https://github.com/arquillian/arquillian-core/commit/f4fef41f8fe812af7376...
> Provide SPI for conditional execution of test methods
> -----------------------------------------------------
>
> Key: ARQ-1902
> URL: https://issues.jboss.org/browse/ARQ-1902
> Project: Arquillian
> Issue Type: Feature Request
> Components: Base Implementation
> Affects Versions: 1.1.5.Final
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Fix For: 1.1.6.Final
>
>
> [~aslak]
> Let me explain.
> We want to do this:
> {code}
> @RunWith(Arquillian.class)
> @RunAsClient
> public class TestCase
> {
> @Test
> @Jira("ARQ-1")
> public void test() {
> // this test method will be executed
> // because Aslak created EJB Jar archive (JIRA status = done)
> }
> @Test
> @Jira("ARQ-xyz")
> public void test() {
> // this methods will NOT be executed (will be skipped)
> // becase lets say that its status is "open / unresolved"
> }
> }
> {code}
> While looking into the code, it seems these classes are most important (1), (2).
> So my initial approach was that I wanted to kind of "hook" into that execution and dynamically resolve if that test method is going to be executed or not but I am failing to do so since there is not any SPI which would load my test-method-execution-decider which would tell if that method is going to be executed or if it will be marked as skipped.
> In that decider, I would dynamically log in to jira and read if that jira is resolved or nor and behave accordingly.
> Is there any will to push this to upstream once implemented? Default decider would indeed execute that method every time and I would just put my own decider and whole JIRA api on class path in my custom extension.
> (1) https://github.com/arquillian/arquillian-core/blob/master/container/test-...
> (2) https://github.com/arquillian/arquillian-core/blob/master/container/test-...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months