[jbosstools-dev] Eclipse Arquillian

Thu Oct 18 12:33:01 EDT 2012

On 17.10.2012 10:55, Max Rydahl Andersen wrote:
> 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 ?

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?

> 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

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.

> 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

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.

> 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 ?

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 ? )

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.

> 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 ?
>   

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.

> 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 ?

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.

>      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)

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.

> 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 ?

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.

> 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 ?

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.

> 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.

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.

> 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"

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 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.

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

> /max
>
>
> On 16 Oct 2012, at 16:59, Snjezana Peco <snjezana.peco at redhat.com> wrote:
>
>> Hi,
>>
>> Could you please review https://github.com/snjeza/arquillian-eclipse?
>> Your suggestions are welcome.
>>
>> Thanks,
>> Snjeza
>>