Jason Porter

Thanks for having us! I know we're all at different conferences this week, so replies have been a bit delayed, sorry for that.

The same practices apply to testing microservices as web services. You may find you'll want more finely grained tests for microservices.

You can draw that boundary in many places, even in "traditional testing." Do you stop testing at the network level, database, firewall, etc? There isn't necessarily a right or wrong place to draw that boundary. There are tradeoffs at each area. More important is to find what works for you and your team and stick to it. It is helpful, however, to have tests of some kind that will target each point of failure.

Yes! There’s certainly usefulness in that. Would you prefer to find out in testing or production that a third party changed their API? You could also contact the third party and offer your tests to them to let them know you expect this contract. If they know you’re using their service they’re more likely to let you know of changes. Certainly worth doing, especially if you don’t have an SLA (service level agreement) with them.

Yes, as I mentioned in another post we talk about some of this in the prose, but mostly you'll find this in the code.

Arquillian uses Selenium in Arquillian Drone and Arquillian Graphene, but if you already have something up and running there may not be much that it will help you with. Arquillian Drone does all the driver setup and adds some nice features around PageObjects, but again, if you're already using those techniques it won't bring a lot to the table, but it may help simplify a few things.

There are also some nicities for Angular in Graphene, but that's about all it will get you for client side.

Are you looking to test just the client side JavaScript or any back end services as well?

Thanks everyone! It's great to be here at the Ranch. I remember quite fondly of asking questions of Dan Allen and his book Seam in Action nearly eight years ago. Those few posts and a desire to learn helped push my career in the current direction. Thank you again for the warm welcome. Alex is at Devoxx this week, so I'm not sure how much we'll see him, but I will do my utmost to answer all the questions to the best of my ability.

Thanks for your interest Toth! I hope we're able to help you on your journey of learning Arquillian.

About the book: can I learn from it how to architect my code so testing it can be easily done? dao-s, etc? I'm using weblogic, any tips for testing on this one?

The book is primarily about testing, we haven't talked much about properly architecting your application to make it easily testable, but it is a wonderful suggestion! You will see things we've done or decisions we've made in the code which will make it easier to test. It doesn't matter which server you're using with Arquillian. Arquillian supports a wide list of containers including

Weblogic

WebSphere

Tomcat

TomEE

JBoss AS 4/5/6/7

Wildfly

JBoss Enterprise Application Platform (EAP)

Glassfish

Jetty

Weld

OpenEJB

OpenWebBeans

I think I got them all

There isn't anything different you need to do here besides change the container adapter dependency and maybe some configuration in the arquillian.xml file. Of course any descriptors you need for your container will also need to be in the microdeployment for the test to deploy correctly.

Specifically for Weblogic there's support for WLS 10 and WLS 12.

Hi Darren, thanks for the questions!f

-are there specific advantage / disadvantage to using arquillian as the same framework for all the types [unit, web or functional, integration] of testing?

Arquillian builds upon all the tools you mentioned. It uses the strengths of each and helps to fill holes in some of their weaknesses. Arquillian is primarily targeted at functional and integration testing. This isn't to say you couldn't use it for unit testing, but because you'd end up deploying to a container for your tests it isn't well suited for the quick turn around you want to see with unit tests. If you want to know how your application will perform in the container you're going to be deploying to, or test a service as a client then Arquillian makes a lot of sense. You'll be able to see, monitor and test your application in as similar of a production environment as you'd like.

-is there a 'stock' pdf-type of report that combines all the testing activities into an 'executive summary' type of presentation?

Arquillian uses Junit (or TestNG) as the test runner. Any reports you have from those tools or aggregate reports you can build from the output will still work with Arquillian. Arquillian itself doesn't create any reports, however, there is the Report extension that you could use to create your own custom reports doing what you suggest, there simply isn't any sort of aggregate report out of the box.

-are there additional features, such as code-coverage reports, that integrate all the testing activities into a single code-coverage (i.e. this part was tested by unit testing and service testing, but this part was only tested by service testing)?

Arquillian integrates well with Jacoco using the arquillian-jacoco-extension. If you're not familiar with it, it is a tool similar to emma or cobertura. You should be able to set it all up and create an aggregate report for your full suite.

JBoss has always had different profiles, but Java EE 6 standardized profiles for servers. The first one is the Web Profile.

Very true. Although we don't have an officially production-ready stamped Java EE 6 container from JBoss just yet (There's M1, and M2 -- which I don't think has been released just yet) but I don't think they're quite up to production quality just yet (please correct me if I'm wrong).

So for production deployment (based on my above assumptions) we have AS 5 if you want to stay with JBoss (or GlassFish v3 which looks very compelling I might add). So you'll end up doing some slimming and tuning to stick with AS 5.

Very nice, thanks! The last time I looked this document wasn't there, so it must have been created over the past few months. Thanks again!

Welcome Francesco Marchioni! I've been using JBoss AS 5 for about a year now, and I've been trying to find a slimming guide (something more than my own trial and error). Slimming to reduce the memory footprint and also decrease the boot time (I hear AS 6 M2 is much faster now, haven't look though). I also want to slim because I'm not using some services (such as EJB2). Briefly looking through the TOC for the book it doesn't look like this is covered. Did I miss it, or is there reference somewhere you could point me to?

I would have thought the first option would work. Try putting it into an outputText and see what you're getting, then go from there.