Java technology zone technical podcast series: Season 3 Dan Allen on the Arquillian testing framework Episode date:

Transcription

1 Java technology zone technical podcast series: Season 3 Dan Allen on the Arquillian testing framework Episode date: GLOVER: I'm Andy Glover and this is the Java Technical Series of the developerworks podcast. My guest this time is a long-time friend of mine, Dan Allen, who is a principal software engineer at Red Hat in the area of JBoss Middleware. He's also the author of Seam in Action. He's been a long-time open source evangelist and currently is the community liaison for Seam and Arquillian. And I thought we'd start out, Dan, by saying or asking, well, first of all, what's going on these days in Red Hat and JBoss? And then specifically, what is Arquillian? ALLEN: Sure. Great to be here, Andy. Thanks for inviting me. Yes. So there's a lot of exciting stuff going on at Red Hat and JBoss. As a matter of fact I've told a lot of colleagues recently, just sort of chatting with them, man, this is really exciting and there's so much stuff going on. So there's this energy right now at Red Hat and JBoss. And a lot of that actually came to culmination at the recent JBoss World where they did this keynote demo. And they integrated a whole bunch of technologies from Red Hat Linux itself, all the way to things like Infinispan, you know, Java EE 6 and AS 7. And anyway, the takeaway from that was that wow, JBoss is doing incredible things. GLOVER: Right. ALLEN: And so we're kind of riding on that wave right now and we're pushing each other a lot. So one of the reasons that we think that that's happened is because, you know, we've always really understood the community and that's just been a key part of Red Hat and JBoss. And I think with the recent things that have been going on in Java, I think we're actually seeing quite a bit of a pickup in innovation within JBoss because, you know, people are looking for wanting to get involved. So we have these projects that we're starting up. And Arquillian is one of them, and it's really stuff that people have never seen before. So Arquillian, specifically, is really about writing real tests. Testing has been obviously a huge thing in software development in the last decade. But I think that the story that we always tell is that a lot of that idea of testing, it's about testing as a methodology. But it doesn't necessarily talk about testing as a solution. So really with Arquillian, it's a test framework but you could really call it a platform. And what it does is it manages the life cycle of a container or an environment. It will deploy the test, enrich the test case with services like dependency injection, and then it executes the test inside the environment. So what we like to say to sort of simplify

2 that is that what Arquillian does is it brings the test to the runtime, rather than having you worry about managing the runtime within the test. GLOVER: Okay. ALLEN: And what's interesting about that is that if you step back for a second and you look at the test, imagine that that test is inside the container before you start writing anything. So when you're in the container, you can say, oh, well, there's these services that I have when I write my app and I have this idea of a component model. So I can do declarative services such as dependency injection, that's kind of like the most popular one, the one that really comes out the most. And I said well, I can use that in the test and therefore I'm applying that same productivity enhancement in the testing that I do in my application. I've already adopted from my application. Why not do it for the test? And once you're in the environment, then you're much closer to the thing that you're testing in its natural environment and it will be behaving the way that it'll behave when it actually runs. So this would sort of be the antithesis...sorry, it'll sort of be the antithesis of mocking because the thing that we've seen is that you have this hierarchy of relationships in your objects. And whenever one object reaches out to another, in a test, you have to worry about that relationship. You have to say, okay, is that other object going to be there? Is it going to be ready? How do I wire it in? So you start doing mocking. And you end up doing more effort...putting more effort into mocking out the things that...the delegate components that, you know, your object under tests needs. Then you do worrying about what it is that you're actually testing. And you know? There's always that risk that you could be faking yourself out by providing good behavior in the mocks and you're never really getting the sense of what would happen if it's not giving you good behavior. So there of course is always room for mocks and you use them to the degree which they make sense. But when you get to the point where what you really want to do is see whether these two components actually work together, does the dependency injection actually take place? Or does this interceptor actually get applied when I'm in the real deal? And I've seen developers a lot of time do something like they'll create test web pages, and on that test web page they'll put a button and the button will, you know, invoke something on the server side because they don't believe that it will actually run. So they want to give themselves that assurance that oh, yes, this actually does work.

3 So when they want that level of assurance, this is what they're looking for. So rather than having to go through all of the plumbing and set up of doing...whether you're doing manually testing, like creating a web page or you want to for instance write a test that does some integration and you have to bootstrap, for instance, Spring, or you have to bootstrap Hibernate or some other model, some other environment. Forget about all that, because all of that's already running wherever you're going to take your application. So, write the test under the assumption that that stuff is just going to be there for you and you can just inject it into your test. And I think the real benefit of this is that you're tests tell you real answers. You can be sure that if you wrote an Arquillian test and wrote the test as though the component is inside the container...and by that, I'll stop for a second and say what Arquillian is actually doing is it's taking your test and the component under test and it's putting it into a known deployable, such as a WAR file or an EAR file and it will actually deploy that to the container. And then Arquillian will remotely control the test execution from the original test runner and control it from within the server. So it's running JUnit or Test NGA, which this stuff is based on top of. It's actually running it inside the server using remote calls. And then it will pull those results back. The nice part of course is that this can run... We've seen some of this stuff before in the past. Right? With things like Cactus. GLOVER: I was going to say this sounds like Cactus. ALLEN: But the main issue there was that there were two very crucial things that Arquillian does that's different. Number one, this stuff works perfectly in an IDE. There's no need for a build. And that's primarily because of Shrinkwrap. Shrinkwrap is an API that builds WARs and EARs, but it builds them in Java. So inside your test case you're actually building up a WAR file using Java. And then it deploys that WAR file without having to do any sort of Maven build, Ant build, any of that. None of that happens. This is all happening after the test runner starts. So really, it's handing off all of this responsibility to Arquillian. So that means you can just right click in your IDE. Say, run as JUnit test or Test NGA test and it's going to run an integration test. So you get that benefit. The second benefit is if you look at an Arquillian test, the container that you're using, the runtime is not referenced anywhere

4 in the test. So what that means is that this same test would work on any container that provides the stuff that you're using in the test. For instance, if you're using CDI, standard dependency injection model in Java EE 6, then obviously the container has to support that. If you're using JPA, if you're using Spring, you know, those models have to be supported by the target environment. But that's obvious. Right? I mean obviously you can't test what isn't there. So, but that's it. There's no reference to a container. There's no life cycle. There's no before, after, any of that stuff is not there. You just write as if all of that's already happened. All the plumbing has taken place for you. And this allows you to really focus on the test logic itself, much like a unit test does except the difference is that unlike a unit test you actually get access to stuff that's in a platform, that's in a runtime. Whereas JUnit's really just giving you access to things on the classpath. GLOVER: Okay. Okay. So I imagine then... So like you were saying, this is an integration, you know. I guess it could even be somewhat of a functional test tool, maybe. ALLEN: Right. Well, that's the nice part about Arquillian. It ranges. I like to say it ranges from all the way down to a two-component integration test...and actually, you could argue that it could also replace unit tests altogether. All the way up to...there are extensions that allow Selenium to be kicked off. So you can write your Selenium test in Arquillian. And then Arquillian handles all of the details of setting up the infrastructure of Selenium; all the remote proxy, actually kicking off the browser, running Selenium, getting the results back and printing it to the console. And that's through an extension called Arquillian Drone. And the reason it's not called Arquillian Selenium is because Drone has actually abstracted away from multiple compatible browser testing tools, which includes WebDriver, Selenium, Core, Original and HTML Unit, HTP Unit and various other, you know, web client testing tools. So Drone just controls whichever provider you want to use. GLOVER: I see. I see. And because all this is built off of or on top of, you know, JUnit and Test NG, then I can still leverage something like Ant or Maven to kick off, you know, an Arquillian test suite. Right? ALLEN: Absolutely. It executes inside your build without having to change anything other than adding a couple more JAR files. And the way it determines which container it's going to be connecting to or starting up will be based on the JAR files. And the interesting thing about the containers is that they're a very wide range of containers, a lot of variety. Right? When we use the word container, that's actually probably too specific of a word. We

5 probably need a more abstract word there because a container could be something like JBoss Application Server or GlassFish. Or it could be an embedded runtime, such as Spring, like a CDI embedded runtime, EGB embedded runtime, a JPA standalone runtime. So the runtime itself is what we're calling the container. So runtime's probably more accurate of a term. And when you do a container, a full-blown container like JBoss AS, you may decide you want to use an existing server that's already running. You may want Arquillian to start the server for you but in a managed way so that it just kicks off the startup script. Or you want to use that server in an embedded mode where you actually use the same JVM. So you have a lot of options as to which container you want to target. If you're writing your test suite, you may say I'm doing all my tests on JBoss AS, nothing else. I don't worry about it. It simplifies life for you, somewhat. Or you could say I need the same test to work across all Java EE application servers. So I will run my test on each one in sequence. You know? Run all the tests on AS 7, then run them all again on GlassFish, then run them all again on WebSphere. So you have the ability to actually see whether the code that you're writing is portable, which is an extremely powerful thing given how much people have been bitten by portability in the past. GLOVER: And so going back to this whole notion of, you know, containers and whatnot, so I'm just curious here. You were saying that, you know, from a configuration standpoint... I guess let me take another step back, because you're sitting on top of JUnit and Test NG, then I, you know, to paint a picture for those of us listening that, you know, aren't watching you code, this is annotation-based testing, right? ALLEN: Yes. To some degree it's annotation-based testing. You use a special annotation, which JUnit provides. Test NGA also provides a similar thing, but the one that JUnit provides speaks a little bit better to what it does. The annotation is called RunWith. And that annotation hands off the orchestration of the test to a delegate. And the delegate that it's handing it off to is Arquillian. So Arquillian will take over and it will start running the test itself. And it will kick off all of the life cycle events that are standard. The other thing that's kind of interesting is that Arquillian adds a whole new set of life cycle events that you can tap into. So it's a completely event-based system. So at any stage during the life cycle, the plumbing that Arquillian is working on, your test can actually tap into that.

6 So this is going to give you a lot of flexibility. And then the primary annotation that comes up once you use the RunWith annotation is, well, there's the deployment annotation and that determines, you know, what is actually going to be in this isolated classpath of your test. And I'll talk about that in a second. And then the other annotation you'll use is some sort of dependency injection annotation because you need to get access to some service or component inside the container. So for instance you might do...you might inject your service beam so that you can invoke it. You might inject like a persistence context so you can play around with JPA. You might inject like a user transaction so you can mess around with the transactions within the test. But since you're inside the container you have access to all these services and you can actually do that in your test. GLOVER: And then going back to kind of the more basic aspect, you were saying that you could test against JBoss or any other container. You don't have to actually configure that in your test? The annotations? ALLEN: Nope. GLOVER: Arquillian just figures it out based on, you know, what libraries you have in your classpath. ALLEN: What libraries are in your classpath and actually, it's cool, Arquillian, in the most recent version -- so this is just before 1.0 is being released, so it will be in the 1.0 release -- that you basically have the ability now... Okay. I'll stage the problem for you and then you'll appreciate what the change was. So let's say I put the JARs in the classpath for JBoss AS or JBoss AS, let's say, the remote adapter. What happens if I have three different remote JBoss ASes that I want to test? Or maybe I have a dev, a QA, you know, and some staging and I want to be able to run my test on any of those. The JARs alone are not telling the whole story. So what we've come up with is this idea of container profiles. And a container profile is a set of ports -- a configuration -- but a set of ports, host names, things like that, actual addresses. GLOVER: Right. ALLEN: So you can say I'm doing JBoss AS Remote. And then there's this configuration file which says here's the profile of that application server I want to use. So then you can toggle between QA, staging and development, just by changing which profile is active. And Arquillian has a little flag that lets you set which one of those you want to do. So it's kind of a cross section between the JARs that are on the classpath and which profile that you're targeting. But

7 this is actually, it really opened up a lot of possibilities because once you realize that you're not... We thought originally, because we were thinking so much about portability, like testing different CDI implementations or testing different Java E implementations to make sure they were compatible, we were focused so much on the different vendors. But then we realized that likely in a shop you're going to be on one vendor but with different profiles. So we're now able to support both axes on that. So that's pretty interesting. GLOVER: So you mentioned the term CDI and I was hoping you could kind of expand upon, you know, for those of us listening, what is CDI? ALLEN: Yes. It's a good question. So if you've ever used Java EE in the past, let's say up to Java EE 5, you would be pretty well aware of the fact that there's no dependency injection model in the platform. There are types of injections and they're specifically called resource injections. For instance, if you want to get access to something in the JNDI Tree or you want to get access to a persistence manager, then okay, you had some dependency injection. But there wasn't a way to just say I have this class and I have this second class and I want to be able to wire them together. And where we would turn is Spring or we would turn to JSF sort of had a primitive dependency injection model, or really more like a component wiring model. And you'd have to go to some other framework. Seam 2 also offered this. And there was nothing in the platform. So CDI stands for Context and Dependency Injection. And it's otherwise known as JSR 299. We go with CDI now because there's actually CDI 1.1, which is a new specification, which is another JSR number. So the model itself we refer to as CDI. And it is a dependency injection model that is based on the type system. So you use annotations to do the dependency injection. And that's where annotation comes into play. And to determine which beam to inject, it first looks at the type. It doesn't look at the name of the field. It doesn't look at an XML file that you have to configure. It looks at the type and it assumes well, if you want to inject that type, there must be only one candidate in your classpath that also is of that type. And it's a concrete type, not an abstract, not an interface. It's a concrete type. What happens if you have two types that are compatible? Then you use another annotation called a qualifier. And a qualifier is a semantic annotation that says -- a semantic construct -- that

8 says I would like that class that provides that specific behavior. So for instance you could have something like a vendor specific. So you could have, let's say you have a URL shortener. You want to have the Google URL shortener or you want to use the tiny URL shortener. You can use a qualifier to say which one of those implementations you want. Then it, you know, it obviously provides you that. GLOVER: Is that qualifier a package name? Or? ALLEN: It is actually an annotation. GLOVER: Oh. Okay. ALLEN: That you can define. So what's interesting is that the annotation, I like to say, supplements the type. So if you look at the type of a beam, it's not just the Java class. It's not just its Java types, but it's the Java types plus any qualifiers it has. So you can get more specific. So what's neat about this, why that matters, is that you can do all of the dependency injection in pure Java but without having tight coupling because you don't ever reference the implementation class. Instead you reference this qualifier data. So the implementation class could be changed over time, but the qualifier would stay the same. So you never have to go off to do XML. And we like to say that it leaves a single source of truth, then, in the dependency injection model. So this is CDI. This is what you see in Java EE 6. If you sit down to write a Java EE 6 application chances are you're going to start working with CDI almost immediately. GLOVER: Okay. ALLEN: Because you're going to immediately start writing business logic and that business logic is going to be broken down into several components and they need to be wired together. So that's where it will come in. Now how this ties to Arquillian. Arquillian is actually a second-generation testing framework. The first generation is the actual test suite for CDI. The JSR 299 specification, every specification has to have a test suite which allows vendors to achieve compliance. There are two interesting things about this test suite. Number one is it was completely new. There is no good test suite to write tests for the specs. The one that you get from the JCP, from Oracle, is first of all, it's got license problems. Right? I mean, you immediately have to get wrapped into this whole license agreement to even use that test suite. And the second thing is it really isn't that good. So we created something completely new. [LAUGHTER]

9 And it was based around the idea that every test would be part of a deployment. And every deployment would go off to the server and the test would be run inside the server. So this idea of doing the life cycle of the container in the deployment came from that test suite. And there was a good reason for having to do that because CDI itself, the only way to verify that actually worked was to verify that it was behaving correctly within the module system of Java EE because of visibility of classes and, you know, cross module visibility and things like that. If you weren't testing in that environment, you weren't testing. Which is why we always say this is about writing real tests. GLOVER: Okay. ALLEN: The other interesting that about that test suite is that it was put under the Apache Software License, which was revolutionary in the JCP. And as a matter of fact it caused a lot of problems, to be honest. Good problems. The type of problems that Red Hat likes to cause because we like to keep software open. And there was this mentality that test suites should be something that's hidden; it should be something that is revealing too much information about some implantation. And we believe as software developers first and Red Hat community members and employees second that testing must be transparent. It's the most important thing of the software. How else can you guarantee to customers that this stuff is stable if you can't show them the test results? [LAUGHTER] So, we believe very strongly in this. And because we put it under the Apache Software License, it enabled us to fork that and start creating a new project which had a broader scope that was able to tackle not only CDI testing, but actually being able to test any component model in Java. And that would include and extend to things like EJB, JPA, JAX-RS, JMS, you name it, we can test it because as we abstracted all of the hard coded reference to CDI out and just had this idea of test enrichers. And the test enrichers would be like intelligence that you assign to the test of awareness of the environment that it's running in. So for instance, if you want to look up an EJB for instance, you would have this idea of an enricher that would know how to look up an EJB. If you wanted to be able to get access to a queue, you would have an enricher that would know how to find a queue. Things like that. So the idea of CDI being provided to the test was just an SPI implantation, it's just an enricher. That's just one use case for Arquillian. But Arquillian is the official testing framework for CDI

10 testing. So if you're like well, I want to use CDI. How do I test it? Arquillian. GLOVER: Arquillian's the way to go. ALLEN: It is. Absolutely. GLOVER: So then where do we find more information about Arquillian? ALLEN: So the best thing to do would be to go to jboss.org/arquillian. And Arquillian is, well, it's A-R-Q-U-I-L-L-I-A-N. Or if you can't remember that, just search for Men in Black and you'll find the reference to the Arquillian species. And that's where we got the name from. GLOVER: I see. I see. And then on the Arquillian website there's obviously examples and whatnot, tutorials, et cetera, that we can start to read and understand exactly how to do CDI-based testing. ALLEN: Exactly. There are tutorials. There's a reference manual. But there's something else that's interesting. When we're going around to do these talks -- and I speak often about Arquillian -- we have a testing showcase. GLOVER: Yes. ALLEN: And that showcase is in GitHubs. All the source code for Arquillian and, really, just about every JBoss project now is in GitHub. So it's github.com/arquillian. In that organization on GitHub is a showcase project. And the showcase project will show you sample tests of how you would test all these different technologies and has everything from CDI to JPA, EJB, JAX-RS, a Selenium-based test and so on and so forth. So it gives you a good idea of the different types of testing that you can do with Arquillian. GLOVER: Okay. And then so, and just to repeat, because you did mention this, Arquillian is on GitHub and it's a top-level organization, so it's just github/arquillian. ALLEN: You got it. GLOVER: Awesome. And then Dan, what about you? You're a prolific writer, a speaker, worldwide traveler. Dan and I were...you and I were laughing as we got online. The last time I saw you...for the listeners that don't know this, he and I actually live somewhat close to each other. But I haven't seen him in a number of years. And the last time you and I met in person was actually in Belgium at what was it? Devoxx. Right? A number of years ago. ALLEN: Yup.

11 GLOVER: So that gives, you know, listeners just a hint on how busy Dan is. So you know? How can we keep up with you, Dan? ALLEN: Well, I'm traveling all around the place. I've been around the United States and Europe speaking. And I keep my...really, the best way to keep up with me now, there's this new website, if you haven't heard of it, lanyrd.com. And lanyard like the things you wear around your neck when you go to a conference. And it's becoming the absolute premier directory for events, not just in software, but just across the board. GLOVER: Right. ALLEN: But the cool part about it is it integrated with Twitter and you're social network. So if you find my handle or whatever on there -- which is the same as my Twitter -- you see all the talks that I have coming up. And then if you go to your own account you can see all of the talks of people that you're following and where they'll be speaking. So if you're following me on Twitter, Lanyrd automatically makes that connection so you can actually find what talks I'll be doing through there. And I always put my talks on Lanyrd just because I've tried a million different ways of communicating where I'm going to be, including blog entries, and nothing beats Lanyrd because it's just a centralized directory and you can get a list of where I'm going to be. You don't have to read my verbose blog entries to find out the times and dates of where I am. So that's the best way to find me. And of course I'll still write up blog entries about why I'm there. But if you want to know just when and where, that's the best place to do it. GLOVER: Well, then, I would highly recommend for our listeners to, if you get a chance, to meet and her Dan talk. It's well worth your time. As you probably picked up on this podcast, Dan is a very passionate developer. He and I worked together a number of years ago and it was immediately obvious that Dan was different in the sense of the level of passion that you have for technology and Java and open source. I know I speak for everyone listening when I say thank you very much for giving us some more information on Arquillian, letting us know what's going on in the wonderful world of Red Hat and JBoss and CDI. And I hope that I get to see you soon. I'm sure our listeners will hopefully stop by and say hi to you at the next conference. ALLEN: Yes. Definitely check it out. I mean I've got this new style of presenting. And Arquillian is probably the premier presentation that I have that I give. And it's really an event. It's really just as

12 much about entertainment as it is about teaching you about Arquillian. So if you come to one of the talks, I guarantee it will be worthwhile for you and we'll have fun together. GLOVER: Awesome. Awesome. Well, my guest again has been Dan Allen. And I'm Andy Glover and this is the Java Technical Series of the developerworks podcast. Thanks for listening. Sweet, dude. What'd you think? ALLEN: Excellent. Very good. [END OF SEGMENT]