4:59 p.m.
Hi,
Could you please review https://github.com/snjeza/arquillian-eclipse?
Your suggestions are welcome.
Thanks,
Snjeza
5:57 p.m.
On 16.10.2012 17:39, Aslak Knutsen wrote:
The following is from the Getting started tutorial
(http://arquillian.org/guides/getting_started/) :
Now, about that flair. An Arquillian test case must have three things:
1. A |(a)RunWith(Arquillian.class)| annotation on the class
2. A public static method annotated with |@Deployment| that returns a
ShrinkWrap archive
3. At least one method annotated with |@Test|
Snjeza
6:07 p.m.
Right, in that context it's needed.
You'll need a Deployment to run "In Container", but you can run without a
Deployment and just work as a standalone client.
You can even run without any Container/Deployment support enabled at all, just as a common
abstraction layer between different test frameworks, but...
Let's assume the most common use case, which is having a Deployment, and leave it as
is for now.
-aslak-
----- Original Message -----
12:03 a.m.
I agree. This is super exciting! Perfect timing too for demoing at
Devoxx and collecting some feedback.
Snjeza, I would love to turn this thread into a blog post on
arquillian.org. It's okay if there isn't a release yet, just the
information about the work in progress is plenty of news to share, to
get people excited and to get them involved.
Would you be willing to redraft the original message and incorporate the
feedback from this thread (so it's up to date)? You can either send it
as an e-mail or, if you are up to the extra challenge, a pull request to
the Arquillian website repo. We write blog posts in textile with a small
metadata block at the top. You can see examples of other blog posts in
the blog directory.
If you are tight for time, I'd be more than willing to format the post
for you so that you don't have to worry about it. What's most important
is capturing the information from you to share.
Again, great work!
Cheers,
-Dan
[1] http://github.com/arquillian/arquillian.github.com
[2] example post w/ lots of detail:
https://raw.github.com/arquillian/arquillian.github.com/develop/blog/2012...
On 10/17/2012 01:22 AM, Xavier Coulon wrote:
--
Dan Allen
dallen(a)redhat.com
Principal Software Engineer
Middleware Engineering
Red Hat, Inc.
11:11 a.m.
On 10/23/2012 12:03 AM, Dan Allen wrote:
That would be great. A list of finished and planned features is
available in the README file on https://github.com/snjeza/arquillian-eclipse
Thanks,
Snjeza
10:55 a.m.
Hey Snjeza,
(cc'ing Andrew since I know he got opinions on arquillian ide integration ;)
cool progress, looking at the videos I got the following feedback:
Add Arquillian support - http://screencast.com/t/gUh1IjTBfnE
A) "Add Arquillian support" mutates/edits the project with zero
warning/information - there should be a confirmation dialog informing what is about to
happen that the user can approve or reject.
B) A bunch of profiles are included (glassfish local, remote, as etc.) I suggest users can
choose which ones they want to include to avoid cluttering their pom.xml.
(maybe would be interesting to provide a way to add these profiles later on since
with this they aren't included by default)
C) I see you are referring to arquillian-bom in here - does this fit with projects where
enterprise=true and -redhat dependencies should/would be needed for some of these ? i.e.
shouldn't there be an EAP profile too ?
D) Can I enable Arquillian on non-maven projects ? (i.e. users that uses mvn
eclipse:eclipse or gradle or ant+ivy would not have m2e installed/enabled for their
project but would still like the various features to be available)
Create test case - http://screencast.com/t/mjoeU7gqkym
A) shoudn't "create deployment()" be enabled by default ?
B) how does this wizard work if the user is using TestNG ? Do we need it behave
differently ?
(if its just a matter of changing the import of junit to testng initally we could
just leave it as is IMO)
Create @deployment method - http://screencast.com/t/OY701ZWeXWsv
A) (minor) The Add buttons should be labeled Add... (three dots) since they open
additional UI
B) "Add" on classes does what exactly ? show all classes on the current project
and its dependencies ?
resource linking - http://screencast.com/t/y8bt7See
This is nice - nuff said! :)
Run As ... - http://screencast.com/t/0cOI6AITkupB
A) The Run As... seem to require/build a custom type of launch configuration, correct ?
This kinda goes against the notion of letting arquillian be "like any other
junit/testng test"
It also prevents usage of this against junit, testng or any other kind of launch -
i.e. if testng adds a feature to their launch this one won't work with/use it.
Should/could this not just be an addon on junit/testng launches ? (i.e. extra tab
which adds in the right system properties ? )
B) the "Test Failed. Connect refused: connect" is not very explanatory. Sounds
like it did connect ...but not really.
What does "test management" actually do ? does it use the as7 server
adapters ?
D) On the arquillian tab I see a table with specific servers - is it meant to be the
server selected is the server used for the run ?
how does this match up with the profiles ? Or is it getting the properties to set
from that server ?
How about other servers than jboss ?
This workflow is a bit confusing to me - I would expect this to be a choice you make
when launching the test, i.e. when running it I get the question which server to run with
and the properties get set based on it ?
(with an option of a "dont ask me again" option to make it remember the
launch settings)
E) Also the start/debug/stop buttons in this UI seems to be the wrong place to have these
? (since you'll never see this page in a normal flow)
F) You write: "The Arquillian configuration properties are added using declarations
from the arquillian.xml, arquillian.properties and the default values when instantiating
the corresponding container configuration."
what does this mean ? that you take properties from all these and then pass in as
concrete system properties or ?
Validation - http://screencast.com/t/53XkyHltg
A) how are the test of missing classes done ? by looking for matching .addClasses methods
in the @Deployment method ?
B) the warning says "import isn't included", we should not use short form of
english words so it should be "import is not included" or dependent on answer of
A: "class not found referenced in any deployment"
Same with "doesn't exist" referring to the resources.
C) I think the severity level should be specified more out than just a global setting.
i.e. "Missing resources/classes in @Deployment method", "Used classes
missing in @Deployment", "Missing @Deployment method"
I think this plugin already got a good set of featuers - my only biggest concern is that
it seem to require its own custom launch config which I find unnecessary and the way to
launch/configure it confusing.
If we could get that worked out we should definitely get this included in JBT 4.x ASAP.
/max
On 16 Oct 2012, at 16:59, Snjezana Peco <snjezana.peco(a)redhat.com> wrote:
11:53 a.m.
also one huge thing missing is that https://github.com/snjeza/arquillian-eclipse seem to
have *zero* tests :(
We can't afford that for such a big feature like this (actually we can't afford it
for any features to not have basic test coverage)
/max
On 17 Oct 2012, at 10:55, Max Rydahl Andersen <max.andersen(a)redhat.com> wrote:
6:33 p.m.
On 17.10.2012 10:55, Max Rydahl Andersen wrote:
I am planing to add a project properties/global preferences page that
would enable a user to define the Arquillian support. The user would be
able to define the following:
- arquillian-bom (comunity GAV, EAP GAV, etc)
- profiles he wants to be included
After that, I would create a dialog according to your suggestion.
Is there any example of an Arquillian EAP project?
Currently, the Add Arquillian support action requires m2e and configures
pom.xml. I can extend this action to other Eclipse projects, but would
need an example of such a project.
A) shoudn't "create deployment()" be enabled by default ?
OK.
I haven't tried TestNG yet, but suppose you are right. The only
difference is in defining a test class.
A) (minor) The Add buttons should be labeled Add... (three dots)
since they open additional UI
OK.
B) "Add" on classes does what exactly ? show all classes on
the current project and its dependencies ?
Only classes in the source folders are shown. I suppose the other
classes from the classpath are already included in the container.
Correct.
I have chosen a separate launch configuration for the three reasons:
- removing the JUnit3 support because Arquillian requires JUnit4
- the Arquillian launch configuration starts only Arquillian tests, not
any JUnit test
- the Arquillian launch configuration checks if there is exactly one
container implementation on the classpath and, if not, it warns the
user. JUnit launch configuration fails without any warning.
As to additional features in the JUnit launch configuration, they will
generally be added to the Arquillian launch configuration because the
Arquillian launch configuration inherited the most of the artifacts of
the JUnit launch configuration.
Regarding "arquillian be like any other junit/testng test" - the user
will be able to use the JUnit/TestNG launch configuration if he doesn't
want additional features the Arquillian launch configuration brings.
If there are the managementAddress and managementPort Arquillian
properties, this action tries to connect using a simple Java socket,
e.g., checks if the managementPort on the managementAddress is open or not.
There is a similar code in the arquillian source tree.
The servers are shown in order the user to see what servers (and their
home location) exist in the workspace as well as if they are started or
not. If an Arquillian test (jbossas-remote, for instance) requires some
server to be started before running the test, the user can start it
without leaving the launch configuration tab. The user can also select
maven profiles if the corresponding JBosTools plugin is included in the
distribution.
You mean that we add a dialog similar to the Arquillian launch
configuration tab when the user starts the configuration?
E) Also the start/debug/stop buttons in this UI seems to be the
wrong place to have these ? (since you'll never see this page in a normal flow)
Those buttons are present to enable the user to start/stop a server
without leaving the launch configuration. It often happens that the user
sets a launch configuration and notices that the server isn't started.
Then he has to leave the launch configuration dialog, find the Servers
view and start/stop the server.
Arquillian checks its properties that way. They are shown in order the
user to see and eventually change them. If the user changes some
property, it will be entered in the arquillian.properties.
Only arquillian configuration properties are shown. We would probably
have to add a default protocol, group properties and other properties
described in the arquillian.xml.
The Arquillian validator works as a compiler participant, creates a
special Arquillian compile environment, finds Arquillian tests and
recompiles them. If it finds an error, converts it to an Arquillian
error. As to "missing resources", the Arquillian validator finds them so
that it tries to create deployment archive. If creating the archive
fails, we create a marker that is "missing resources" in most of the cases.
If there are JDT compile errors, the Arquillian validator isn't started
at all. I think, Arquillian errors are irrelevant if JDT errors already
exist. Overall performance are better if we skip validation of a Java
project that includes a JDT error.
I can change the messages related to missing classes.
However, the messages related to the resources are created based on an
exception that is thrown when creating a deployment archive. For
instance, "XXX doesn't exist or can't be accessed" comes from the
shrinkwrap project.
OK. I will add the ARQUILLIAN_LEVEL attribute to the marker. The
attribute can also be used in the properties/preferences page to
enable/disable some markers.
I can add the Arquillian tab to the JUnit/TestNG launch configurations,
but some of the mentioned features of the Arquillian launch
configuration probably won't be possible to implement.
If we could get that worked out we should definitely get this
included in JBT 4.x ASAP.
Currently, I am working on the Arquillian View. When I add that feature
and some tests, we could include the plugin in JBT.
Snjeza
4524
days inactive
4531
days old
jbosstools-dev@lists.jboss.org
11 comments
6 participants
participants (6)
-
Aslak Knutsen -
Dan Allen -
Fred Bricon -
Max Rydahl Andersen -
Snjezana Peco -
Xavier Coulon