1 2 Previous Next 16 Replies Latest reply: May 1, 2012 6:16 PM by Aslak Knutsen RSS

Speed up test development

Bernard Labno Master

Hi Guys,

Writing tests usually requires tweaking, running, tweeking, runnint, and so on. Having tests run in container increases the turnaround sky high.

I've been using JSFUnit for Seam2 application and there I made the tests to be seam hot deployable components which allowed me to deploy archive to the server once, run tests, hot deploy, and run them again.

That was a huge boost.

Would it be possible to do something like this in Arquillian? Or what else can we do to speed up test development?

  • 1. Re: Speed up test development
    Aslak Knutsen Master

    I have been playing a little with a JRebel extension to Arquillian, but it's not done yet..

     

    It should basically let you deploy to the server once, then in addition add the rebel.xml file that points back to local disk. The next deploy is then only written to disk and handled by the JRebel classloaders.

     

    I can push it out to github if you want to play with it. .

  • 2. Re: Speed up test development
    Bernard Labno Master

    Aslak, please publish it to github. I'll test it. JRebel was next thing that came to my mind.

  • 3. Re: Speed up test development
    Aslak Knutsen Master

    It's been a while since I looked at it.. don't expect it to work, it's a very early prototype..

     

    https://github.com/arquillian/arquillian-extension-jrebel/tree/wip

     

    But you're welcome to hack away on it..

  • 4. Re: Speed up test development
    Bernard Labno Master

    Aslak, I've tried to do anything with that extension but the problem is it tries to serialize ProtocolMetaData which is not serializable and contains stuff that varies depending on protocol and container type so I have no clue where to go now.

    When will you be on IRC again so we could talk this over?

  • 5. Re: Speed up test development
    Aslak Knutsen Master

    Aaa yes.. that's right. Forgot about those, probably why it never got published in the first place. It relies on a few changes to Arquillian Core.. which is probably have in some old branch here..

  • 6. Re: Speed up test development
    Bernard Labno Master

    Ok, we've got the extension working for servlet protocol.

    Before further discussion I've noticed that we can solve (or at least workaround) issue with one deployment per many test classes (ARQ-197). Simply we can check either archive name or deployment name if we find archive exported to temp dir then we do not deploy it.

     

    And now we come to an issue, but maybe let's list all the issues now:

    1. How do we name exploded directories?
    2. How do we tell that exploded archive is for particular deployment?
    3. What do we do if dev wants to customize rebel.xml?
    4. Undeployment

     

    Ad 1.

    We could take the name of deployment if it's not default or the archive name in opposite case. I think we should allow situation where user runs tests from class A then tests from class B and then again from A. So we probably will need separate exploded directories.

    We should also use the same name ans prefix for meta file (serialized ProtocolMetadata).

    This would force user to name deployments or archives differently if they have different contents.

     

    Ad 2.

    This is connected to point 1. Right now there is only one exploded package directory and it's used as marker file telling if package is deployed.

     

    Ad 3.

    Dev can want to modify classes that are packaged as library (i.e. in WEB-INF/lib/) so he would need to add classpath entry to rebel.xml.

    I imagine 2 solutions:

    • dev packages their rebel.xml into deployment and extension parses that file and adds "war" entry
    • if dev packaged rebel.xml into deployment then extension does nothing, its dev's responsibility to configure rebel.xml right

     

    Ad 4.

    Currently the extension blocks undeployment so the package remains on the server all the time and when we do i.e. mvn clean test then extension tries to redeploy the archive but Oops, AS7 will throw exception because package with such name is already deployed and the tests will run against old (already deployed) archive.

    Probably if we don't see marker files and think we need to redeploy then throw undeploy event first?

  • 7. Re: Speed up test development
    Lukáš Fryč Master

    Hi Bernard,

     

    at first, this is fanstastic achievement, I can't wait to try this extension!

     

    Few comments here:

     

    Ad 2.

    This is connected to point 1. Right now there is only one exploded package directory and it's used as marker file telling if package is deployed.

     

    Does it make sense to prefix the deployment name with FQN of test class?

     

    Then there will be no clash, you could name exploded directory by test class name.

     

    Ad 4.

    Currently the extension blocks undeployment so the package remains on the server all the time and when we do i.e. mvn clean test then extension tries to redeploy the archive but Oops, AS7 will throw exception because package with such name is already deployed and the tests will run against old (already deployed) archive.

    Probably if we don't see marker files and think we need to redeploy then throw undeploy event first?

     

    What if the extension could "cache" only last scenario (it means all deployments for class which was run last).

  • 8. Re: Speed up test development
    Bernard Labno Master

    Does it make sense to prefix the deployment name with FQN of test class?

    What if there are multiple deployments in single class?

     

    What if the extension could "cache" only last scenario (it means all deployments for class which was run last).

    Why limit like that if it's already possible to cache all deployments? If you want to force redeployment then remove temp dir.

  • 9. Re: Speed up test development
    Aslak Knutsen Master

    Arquillian internal rules say:

     

    A @Deployment.name must be unqie within a TestClass if

    - there are more then one Archive Deployment in the TestClass

     

    A Archive.name returned by a @Deployment method can be the same but only if

    - the @Deployment has different @TargetsContainer

     

    TesClass + Target + Deployment.name should be unique

     

    @Inject Instance<TestClass> testClass;

     

    testClass.get().getName() + event.getContainer().getName() + event.getDeployment().getName()

  • 10. Re: Speed up test development
    Aslak Knutsen Master

    Why limit like that if it's already possible to cache all deployments? If you want to force redeployment then remove temp dir.

     

    My first thought was to only have one deployment active at the time. So you would run one test, rebel kicks in. run it again, rebel is active. But when you run another test, the previous run is undeployed, new test run, rebel kicks in.. etc

     

    But there might be better ways of doing this. Maybe it's ok that sometimes you have to go clean up the servers deployment manually during dev ?

  • 11. Re: Speed up test development
    Lukáš Fryč Master

    I currently see only the one use case, where one deployment scenario is cached, since you are hacking on that.

     

    And having one deployment scenario (multiple deployments) seems like overall simplification.

     

     

    Could you see any other use case?

  • 12. Re: Speed up test development
    Aslak Knutsen Master

    not sure i understand what you mean by "

    And having one deployment scenario (multiple deployments) seems like overall simplification." ?

  • 13. Re: Speed up test development
    Lukáš Fryč Master

    I mean that it could simplify design heavily, since you don't need to solve conflicts which can arise with many deployments.

    You can be sure that there are only deployments related to current class deployed at the time.

  • 14. Re: Speed up test development
    Aslak Knutsen Master

    Yea, I think it's atleast a good start for the first version. JRebel is something you would use in a pure dev setting, not on CI etc. As long as we can jump between tests seamlessly, I don't think the undeploy of the previous testcase should be to much of a hassle.

1 2 Previous Next