agimatec » Selenium

Javascript Unit Tests with the YUI TestManager

Simon Tiffert — Thu, 29 Jan 2009 14:02:30 +0000

Testing your Javascript is very important. Especially when the amount of code is growing and growing.

The easiest method are unit tests. We have tried several JS unit test frameworks. Including JSUnit, Scriptaculous Unit Test Runner and YUI test. With a lot of YUI components like the YUI Loader and many YUI widgets we refactored our unit tests to use YUI Test. We like the Yahoo User Interface because of its documentation and also of its code quality.

YUI Test is not bundled with YUI. You can use it with YUI but we also use other frameworks like Prototype and DWR. To learn more about YUI Test you can watch the presentation of Nicholas C. Zakas.

Ok, this is great, now I can test my Javascript. But wait, what is if I have a lot of Javascript. I can group my tests in test cases and test cases in test suites. This is supported. But while the amount of Javascript is growing one file for all tests isn’t enough. We have a lot of different modules. Each consists of a lot of test cases. Sure, you can copy them all together in a file which is several thousand lines long. But every test run takes then a lot of time, debugging is more complex and it is more complicated to manage this file.

YUI TestManager

Wouldn’t it be great to have a test runner. A script which takes a lot of unit test files and run them one after another. Our first approach was based on the Scriptaculous Unit Test Runner embedded in a frameset. We had a navigation frame and some Javascript included to run one unit test file in the main frame. One problem was to collect the results of all unit test files. We patched the Unit Test Runner and collected the data. It was ok and I wanted to refactor the solution to publish it. After starting I suddenly found an undocumented feature of YUI Test – The YUI TestManager. It is exactly what I wanted to do, define the unit test files, run through all of them and collect the results. I think Yahoo is using this feature internally and didn’t talk a lot about it. But it is included in the API, so please YUI team, include it to the documentation. It is a great piece of code.

Continuous Integration of Javascript with Selenium

Before I will show you how to use it, some more thoughts about this. We are coming from the agile Java world. So continuous integration is very important for us. Please search for “Continuous Integration Javascript” in your search machine. There are just a few hits and no ready to use solution. Yes, you can try to go back to the Java world and run tests with Rhino. There are some Java based unit test frameworks for Javascript. But there are two downsides. You are leaving the Javascript world and you are leaving the browser. It can be ok for you but I don’t trust the different browsers. I want to be able to run the tests fast in the browser when I’m developing and I want to test as many browsers as I can. We searched for a solution and what we have running is a suite of Selenium tests. They are at another level. Functional tests which run through use cases in the web frontend. But if we could give them a result of our unit tests we are able to include this in our setup. Then we can run the unit tests in IE, Firefox and Opera automatically.

YUI Test gives you the logger to view the results of your tests. It is not the best view for test results but it is ok. Also there are a lot of events which include the results of the tests after running them. We have implemented a little script which displays a nice summary which we test with Selenium.

Source code

Now let’s head to the source code.

At the beginning we need a unit test. Because I’m want to concentrate on the TestManager you will find a very very simple test.




    String test

In the first part we define our tests. In the second part you will see that the test will be called after the DOM is ready. It is a little bit different from the normal examples, because we call parent.TestManager.load() if it is available. Now you can copy this code, write your own tests, define test suites, … It starts to get interesting, if you have so many tests, that you want to group them into different files. With the code above you can go ahead and create multiple tests. In the example code I have created to test files calcTest.html and stringTest.html.

To run all tests in all your test files you need to call the TestManager:




    JS Unit Tests
    

    
    
    

    
    
    

    
    

    
    



JS Unit Tests

That’s simple, isn’t it?

That will give you the following output:

We wanted to give it more the feeling of a unit test suite. As I told you there is an event after test completion, which includes the test results. With our script we are building a summary table which gives you a nice overview for your test results.

With the overview table we also can track the results with a simple Selenium test:

package com.agimatec.ostium.portlets.jsunit;

import com.agimatec.ostium.portlets.util.ScreenshottingSelenium;
import com.thoughtworks.selenium.Selenium;
import org.testng.Assert;
import org.testng.Reporter;
import org.testng.annotations.*;

public class JsUnitTest {
    Selenium selenium;

    @BeforeMethod
    @Parameters({"selenium.host", "selenium.port", "browser", "baseUrl", "ostium.login",
            "ostium.password"})
    public void startSelenium(
            @Optional("localhost")String host,
            @Optional("4444")int port,
            @Optional("*firefox")String browser,
            @Optional("http://localhost:8080")String baseUrl
    ) throws Exception {
        Reporter.log("Running selenium");
        selenium = new ScreenshottingSelenium(host, port, browser, baseUrl);
        selenium.start();
    }

    @Test
    public void checkPassedJsUnitTests() throws InterruptedException {
        selenium.open("/portlets/ostium/utilities/ajf/src/test/javascript/testrunner.html");
        for (int second = 0; ; second++) {
            if (second >= 60) Assert.fail("timeout");
            try {
                if (selenium.isElementPresent("//div[@id='testcontainer']/div/h2")) break;
            } catch (Exception e) {
            }
            Thread.sleep(1000);
        }

        Assert.assertTrue(
                selenium.isTextPresent("exact:Result: Passed"),
                "The result of the JS tests should be 'PASSED'.");
    }

    @AfterMethod
    public void stopSelenium() {
        Reporter.log("Stopping selenium");
        selenium.stop();
    }
}

The only thing to do is to run the files on a local server. We use a Jetty with Maven to host the files because Selenium needs to include a proxy which didn’t work if you access the file directly.

Find more to Selenium on our other posts:

Download the script and some examples here. We are planning to release it with some other JS stuff as a Google code project, but we are still searching for a name.

If this post was helpful or you have additional ideas, please don’t hesitate to comment.

Selenium-Flex-Tests with Maven

Simon Tiffert — Thu, 13 Nov 2008 19:05:05 +0000

I wanted to integrate our Flex application with tests into our Maven build. A few days ago I moved the app to Flex 3 and changed the Maven Plugin from the Maven2 Flex Plugin to Flex-mojos. Now the artifacts are in the repository and you don’t need to install the Flex SDK to build the application.

We have written the application as a demo in the first place and now wanting to test it in the wild. Because we use Cairngorm the application is well structured and contains as view layer only minimal parts of logic. Yes, we could include unit tests, but integration tests are far more interesting (from my point of view). In a large code base it could happen, that because of refactoring some things are broken. No deal, if you have tests and a CI system. But in the Flex app there are just tiny parts which I could test in a normal unit test.

Okay, so it should be integration test. Sounds good and not too complicated. There should exist a lot of frameworks because a lot of people start to use BlazeDS and other stuff in Java environments. Just something to start the app, run some tests and get the result back in the CI system.

I started to search on google and was surprised. Most of the blog posts I have found on that topic are just two month old. And there are not so many posts about that topic. With the combination of those posts I figured out, how to solve that problem. What problem?

Integration tests of our Flex app
Integrated in Maven
Should work together with Cairngorm (would be more complicated with some unit tests frameworks)
Could be Selenium (to start the app and run tests)
Should be integrated in our continuous integration server TeamCity
Could be written in Java

First thanks to the blog post of Julia at Blackpepper. She opened my eyes how to work with Java and Flex in combination. It is the combination of the SeleniumFlexAPI, which integrates as Flex to Javascript bridge in your Flex application and FlashSelenium.

SeleniumFlexApi is in one part a Flex library which needs to be included in your app and on the other part an extension to the Selenium IDE. I like the Flex part, because it makes it easy to dive over Javascript into the details of your Flex app. What I don’t really like is the Javascript extension. Yes, it is not only a Selenium IDE part and you can include it into the start of the Selenium Server, but it is far away from Java and Maven.

FlashSelenium is a piece of code which let’s you talk from Java over Selenium with your Flex app. The Java part is very handy, but you need to code into Flex, which methods you could call over your bridge. So I need to write special code, which opens the bridge. The SeleniumFlexAPI is much better in this part.

I liked the solution of the blog post and started to implement it.

First the pom.xml where you need to include the SeleniumFlexAPI (the scope cost me some time):



   
        agimatec
        assessor
        1.0-SNAPSHOT
        ../pom.xml
    

  4.0.0
  agimatec
  assessor-flexapp
  swf
  ${agimatec-assessor-version}
  Assessor Flex Application
  http://www.agimatec.de

  
    		 
		
			com.adobe.flex.sdk
			playerglobal
			3.0.0.477
			swc
		
		
			com.adobe.flex.sdk
			flex
			3.0.0.477
			swc
		
		
			com.adobe.flex.sdk
			framework
			3.0.0.477
			swc
		
		
			com.adobe.flex.sdk
			framework
			3.0.0.477
			resource-bundle
			en_US
		
		
			com.adobe.flex.sdk
			rpc
			3.0.0.477
			swc
		
		
			com.adobe.flex.sdk
			rpc
			3.0.0.477
			resource-bundle
			en_US
		
		
			com.adobe.flex.sdk
			utilities
			3.0.0.477
			swc
		
    
      com.adobe.cairngorm
      cairngorm-bin
      2.2.1
      swc
    

      
        org.openqa.selenium
        flex-api
        0.22
        swc
          internal
      

		 
		
			flexunit
			flexunit
			0.85
			swc
			test
		
		
			flexunit.junit
			flexunit-optional
			0.85
			swc
			test
		
  

  
    src/main/flex
    
      
        info.rvin.mojo
        flex-compiler-mojo
        true
        
          
            ${project.build.sourceDirectory}
          
          
            en_US
            de_DE
          
          true
        
      
      
        info.rvin.mojo
        asdoc

To get the Flex application compile with Maven you need to download the SeleniumFlexAPI and include the swc-file into your Maven repository, because it is (not yet) available on public repositories.

After compiling you can start the Selenium IDE and load the extension or go directly to FireBug and try to call the methods. Be aware, that the args-parameter is normally optional, but needs to be filled for the Javascript-Flex bridge (also cost me some time).

To call a method of your running application in Firefox fire up in FireBug’s console:

window.document['AppName'].getFlexExists('NameOfAnElement','');

To test your application you need to know, what the name of your application is (can be found in the HTML calling the Flash file) and you need to give ids to your elements, because there is just an id locator at the moment.

If you are at this point we can now switch to the Java part with Selenium. Selenium is just Javascript when you are in the browser. So all you do is to call the Javascript function which you called before over Firebug. FlashSelenium is a good wrapper for that call which means that you don’t have to write normal strings into your Selenium commands. I like a little bit more comfort and wanted to wrap the SeleniumFlexAPI a little bit closer. Also there are some methods in the FlashSelenium you don’t need with this solution. So I started to implement my own little wrapper. Maybe it is also interesting for the SeleniumFlexAPI (if completed with all methods).

Here is the beginning of the code:

package com.agimatec.assessor.selenium;

import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.Selenium;

public class FlexSelenium {
    Selenium selenium;
    String flexApp;

    public FlexSelenium(String ip, int port, String browser, String url, String flexApp) {
        selenium = new DefaultSelenium(ip, port, browser, url);
        this.flexApp = flexApp;
    }

    public void start() {
        selenium.start();
    }

    public void open(String url) {
        selenium.open(url);
    }

    public void stop() {
        selenium.stop();
    }

    public String doFlexClick(String id) {
        return callFlexBridge("doFlexClick",id);
    }

    public boolean getFlexExists(String id) {
        return callFlexBridge("getFlexExists",id).equals("true");
    }

    private String callFlexBridge(String method, String id) {
        return callFlexBridge(method, id, null);
    }

    private String callFlexBridge(String method, String id, String args) {
        if(args == null || args.trim().equals("")) {
            args = "''";
        }
        return selenium.getEval("window.document['"+flexApp+"']."+method+"('"+id+"',"+args+");");
    }
}

And now the test case is the only thing which is missing. I used TestNG because it can be easier configured in a Selenium environment (when it started to become more complicated with several browsers, plattforms, test suites, test groups …):

package com.agimatec.assessor.selenium;

import org.testng.annotations.Test;

public class AssessorTest {
    private final static String URL = "http://192.168.1.175:8080/assessor-webapp";
    FlexSelenium selenium;

    @Test
    public void setUp() throws InterruptedException {
        selenium = new FlexSelenium("192.168.1.254", 4444, "*firefox", URL, "Terminal");
        selenium.start();
        selenium.open(URL);
        while(!selenium.getFlexExists("videoPlayer")) {
            Thread.sleep(1000);
        }

        selenium.doFlexClick("videoPlayer");
        Thread.sleep(300);
        selenium.doFlexClick("enterUserModeButton");
        selenium.stop();
    }
}

Perfect Selenium Setup

Simon Tiffert — Fri, 24 Oct 2008 14:15:45 +0000

It takes some time, but I’m now nearly happy with our Selenium setup. In this series I want to explain what goals existed and how we get a larger suite of Selenium tests running.

You can find some posts around Selenium in this blog, but I want to get in more detail. Also there are some improvements to the solutions which could be really interesting if you start with Selenium or get an idea, how others deal with larger Selenium test suites. I will try to publish a new part every week, because there is so much to say, which wouldn’t fit into one single post.

Goals:

Continuous integration of web application tests
Tests in different browsers
TestNG Setup
Integration in Maven2
Faster Selenium tests

Tests:

Running use cases of the web application
Running Javascript Unit Tests in different browsers
Take screenshots of the application

I’m a web developer and no full-time tester, that’s why you should see the posts as support in an agile environment. There are different solutions and methods to test a web application, but I feel very comfortable with coding my tests and provide solutions which helps in the day-to-day work.

Until I will continue with the series, you can have a look at the previous posts:

Testing of Web 2.0 interfaces (in german, but you will understand the code part)
Robust portlet testing
Selenium CI tests with TeamCity
Selenium testing of massive Ajax Apps

Selenium Testing of massive Ajax Apps

Simon Tiffert — Wed, 06 Aug 2008 19:36:40 +0000

Testing of a web application is a hard work. You don’t handle with data in a direct way. You got a lot of markup around it. How to handle this in a flexible and more robust way could be found in the post Robust Portlet Testing.

If you have fought your way through the markup, you now get to another trap on your way to get your tests flying. The markup is changing, because you are using the Ajax technology. After the page is rendered there are asynchronous calls changing your DOM. You are asking: Where is the problem? The problem of testing is, that you need to teach your test tool, to look at the page in the same way you are looking at it. On the first look you want to get the third row of the table. But wait, it is still loading, even if there is just a minimal delay. If you do automatic tests they should run through all the tests as fast as possible. The tool is not to twiddle one’s thumbs to click on the button.

You need to write your tests in another way. The question isn’t only if the data could be found in the DOM, it is changing to if the surrounding element has loaded could the data be found then. And this is the essential point, where most recording tools like Selenium IDE are failing. It doesn’t give you a hint, what is loading after the DOM is ready the first time. Yes it is possible to add pause or a waitForElement-function before every field, but wouldn’t it be easier to have little helpers for the case.

First let’s have a look at how the waitForElement-function in Selenium is working in Selenium-RC:

for (int second = 0; ; second++) {
    if (second >= timeout) throw new ElementNotFoundException("Element not present: " + locator);
    try {
        if (this.isElementPresent(locator)) break;
    } catch (Exception e) {
    }
    Thread.sleep(1000);
}

It is polling every second, if the element specified be the locator could be found. That is better than adding a pause. Why?

How long does your pause needs to be? 500ms, 1s, 2s? You are not sure about it, I am sure. It is a guessing and it is really slowing down your tests. You have 20 elements in one test. And let’s say you’ve got 50-100 tests at the beginning. Well – you are pausing damn long.

That’s why you should start using the waitForX-functions of Selenium. Now nearly every line of your massive Ajax test has a previous waitForX-function. It doesn’t make your tests more readable, but more stable and as fast as possible.

Now we are in a Java world, writing our Selenium tests and are tired of writing waitForX-functions. The next step is to extend the DefaultSelenium class and adding some tiny helper functions:

safeOpen
safeGetText
safeGetValue
safeClick
…

All these functions are equivalents of the normal Selenium functions, but having a waitForX-function build-in. Normally you are saying: getText for this element and giving a locator. Now use the locator to do a pre-test of the element. If the element could be found, get the text. It is just a little helper, but it makes your tests much cleaner and robust.

We have introduced another trick for the safeOpen function. Because we are fetching our dependend Javascript files asynchronously after the normal rendering has finished (check out the YUI Loader), we add a new element with an id after the Javascript has finished its loading process. Now we can poll if the element is in the DOM and start after all the Javascript has loaded.

Check out the following example and try out how it helps to speed up writing your Ajax tests and reduce the test to the test.

See the following example test. Even if you don’t understand which application is tested, you can read the test:

    @Test(dataProvider = "users")
    public void testUserDetails(User user) throws InterruptedException, ElementNotFoundException {
        selenium.safeOpen(URL);

        // fill in search form
        selenium.safeType(
                browserXPath().elementByClassName("searchForm").textField().toString(),
                user.getUserIdentification());

        selenium.safeClick(
                browserXPath().elementByClassName("searchForm").submitButton().toString());

        // action to detail portlet with service menu
        selenium.safeClick(
                browserXPath().table().tr(1).td(1).a().toString());

        // check if all fields are available
        String[] userDetails = {user.getUserIdentification(), user.getGender().toString(), user.getFirstName(), user.getLastName(), user.getEmail(), user.getMobilePrefix(), user.getMobileNumber()};
        for (int i = 1; i <= userDetails.length; i++) {
            selenium.waitForText(detailXPath().table().tr(i).td(2).toString(),
                    checkEmpty(userDetails[i]));
        }
    }

To see the “unbelievable magic” behind the scenes, check out the AjaxSelenium extension:

import com.thoughtworks.selenium.DefaultSelenium;

public class AjaxSelenium extends DefaultSelenium {
    public void safeClick(String locator) throws ElementNotFoundException, InterruptedException {
        this.waitForElement(locator);
        this.click(locator);
    }

    public void safeOpen(String pageUrl) throws InterruptedException, ElementNotFoundException {
        this.open(pageUrl);
        this.waitForPageToLoad("30000");
        this.waitForElement("//div[@id='javascript-loaded']");
    }

    public String safeGetText(String locator) throws ElementNotFoundException, InterruptedException {
        this.waitForElement(locator);
        return this.getText(locator);
    }

    public String safeGetValue(String locator) throws ElementNotFoundException, InterruptedException {
        this.waitForElement(locator);
        return this.getValue(locator);
    }

    public void safeType(String locator, String text) throws ElementNotFoundException, InterruptedException {
        this.waitForElement(locator);
        this.type(locator,text != null ? text : "");
    }

    public void waitForElement(String locator) throws ElementNotFoundException, InterruptedException {
        for (int second = 0; ; second++) {
            if (second >= timeout) throw new ElementNotFoundException("Element not present: " + locator);
            try {
                if (this.isElementPresent(locator)) break;
            } catch (Exception e) {
            }
            Thread.sleep(1000);
        }
    }

    public void waitForText(String locator, String text) throws InterruptedException, ElementNotFoundException {
        for (int second = 0;; second++) {
            if (second >= timeout) throw new ElementNotFoundException("Text '" + text + "' in element '"+ locator +"' not present.");
            try {
                if (text.trim().equals(this.getText(locator).trim())) break;
            } catch (Exception e) {}
            Thread.sleep(1000);
        }
    }

    public void waitForValue(String locator, String text) throws ElementNotFoundException, InterruptedException {
        for (int second = 0;; second++) {
            if (second >= timeout) throw new ElementNotFoundException("Text '" + text + "' in element '"+ locator +"' not present.");
            try {
                if (text.trim().equals(this.getValue(locator).trim())) break;
            } catch (Exception e) {}
            Thread.sleep(1000);
        }
    }
}

Selenium CI Tests with TeamCity

Simon Tiffert — Wed, 30 Jul 2008 14:33:08 +0000

TeamCity’s build agents are great. You can build a grid of servers running your continuous integration tests. This speeds up the build process when there are many commits over the day. But there is another great feature of the grid:

You can setup different environments for your builds. Think of Java version, operating system, databases and browsers.

These are great news for web frontend tests because you can setup a clean environment with all your needs. Just fire your Selenium-Rc with TestNG against this agent.

There is just one problem: You shouldn’t install the build agent for the browser tests as service. We setup a new Xen container for the tests and no browser was visible. It was in the TaskManager but won’t show our tests.

After searching in Google and asking (the really fast) JetBrains support the solution is to start the agent from the command line. To get the agent running after reboots just write a little bat file and place it in the autostart folder:

cd C:\TeamCityAgent\bin\
agent.bat start

Another tipp is to install a VNC server, because if you are using remote desktop you are stealing the Windows session.

Robust Portlet Testing

Simon Tiffert — Mon, 28 Jul 2008 20:13:03 +0000

Robust and durable

Testing of web applications isn’t easy. If you are in a portlet environment things getting even more complicated. A portlet is a web application for itself and there could be a lot of different combinations on every page. There could also be many instances of each portlet on a page.

What are the consequences?
You couldn’t use normal ids on tags, because ids are unique on a page which conflicts when many instances of the portlet are on the same page.

A portal is themeable. The design and also the HTML structure depends on the user settings.

Portlets could be rearranged on a page, which means that the HTML structure is changing every time a new portlet is on a page or a portlet is moved to another place.

Lessons we learned with portlet testing

Nice but unstable

Try to write your tests as robust as possible. Nothing is as painful as seeing your test suite fallen to the ground.

You are developing a new theme or modifying your old one and all locators, in all tests, every field is broken.

You have a defined a set of portlets. Suddenly you need new portlets in this setup. You added the portlet at the top of the page and the tests are broken again.

Make portlet testing fun again.

Using XPath the right way

There are three tipps:

Isolation
Wildcards
Abstraction

Isolation:

Normally there is a surrounding div-container with an id of the portlet instance. Try to use this element as entry point for your XPath. If you use the generated XPath expression of a tool like Selenium IDE, XPath Checker or other tools you will never get structured expressions which are easy maintainable.

//div[@id='agimatec_portlet_curatorArcaeEdit__CuratorArcaeEditPortlet_WAR_ostiumcuratorarcae__editParcel']

Wildcards:

I have never seen a portal source code with a really clean html structure. Because there are many columns, many layouts, many supported browsers you end in a kind of tag soup. Yes you can get an XPath expression with 20 elements. As mentioned there are tools which are generating the expression, but one change and you are doing the work again. Use a kind of wildcards in XPath. With the isolation you are at the portlet instance and right into your own code. Maybe there is just one table inside the portlet, but a lot of more div-layers between the table. With the // syntax you can navigate recursive to the next child element of that type.

//div[@id='agimatec_portlet_curatorArcaeEdit__CuratorArcaeEditPortlet_WAR_ostiumcuratorarcae__editParcel']//table/tr[1]/td[2]

Abstraction:

Don’t write the same code again and again. Write a helper which constructs the XPath for you. If you use a framework to build your forms, you can write a library which navigates directly to the form elements. XPath expression aren’t fun. It is better that it hurts one person than the hole team. Strive for abstraction.

detailPath().tab(1).ostiumTable().tr(1).td(2).toString())

Conclusion

There are a lot of tools for test recording. If you are using Selenium it is the Selenium IDE, if you use WebTest there is the WebTest Recorder. These tools are great for starting your web tests. But if your test suite is getting larger and you are working in an agile environment things are changing. Things are changing to often for maintaining recorded tests.

Learn with recorders but test with logic

Maven2 Build Lifecycle

Simon Tiffert — Tue, 15 Jul 2008 19:45:55 +0000

When you start building your large project with Maven2 it is not easy. You need to understand the concepts behind Maven2. One concept is the build lifecycle, which will be explained in this post.

Why is it important? I always call mvn clean install and everything is running.

For a simple project this is no problem, but in a real world project you need to know what is happening behind the scenes.

The default lifecycle consists of the following phases:

validate
compile
test
package
integration-test
verify
install
deploy

If you call mvn install in the default lifecycle, all phases until install will be running. Let’s step through the phases:

Validate: Check if all the pom.xml-Files in the project are valid and if all information for the build is available

Compile: Compile the source code, nothing special in here. For information where the compiled files are stored, check the default directory layout in Maven2.

Test: If nothing special is configured and you have stored your tests under src/test/java, the Surefire-Plugin will run your tests and generate reports

Package: If you are building a JAR, WAR, EAR or something else, it will be packaged in this phase. This is very important if you want to include sources into the package. Then you need choose a phase before the package phase is running.

Integration-Test: In this phase you can run your integration tests. Some phases have a pre- and post-phase, where you can prepare some things. We use it to start and end selenium to run our web tests in this phase. If you are testing something else, maybe Cargo then you will the pre- and post-phase useful to start and end your server(s).

Verify: Verify the generated package (I have never used this phase)

Install: This phase is important because the package (and its pom.xml) will be installed in the local repository. If there are dependencies to this project, it will be searched in the local repository.

Deploy: The deploy phase installs the package in the remote repository. In our environment this is the main proxy Archiva. Packages are build nightly in the CI-Server to be available for all developers. This phase could also be used, to deploy the hole project into a server.

Other phases:

You need to have a closer look at the phases if you need to generate (re)sources. To process our javascript (minify, verify with JSLint, …) we make heavy use of the following phases before the compile phase starts:

generate-sources
process-sources
generate-resources
process-resources

There are a lot of pre-configured goals defined for the lifecycle. Which goals are defined depends on the choosen packaging (JAR, WAR, EAR, …). You normally don’t need to know which goals are running, because they will fit to your packaging. If you need to hook into the lifecycle you configure your plugins to run in the appropriate phase. One the hand it is important to find the right phase that e.g. your resources are packaged, on the other hand we often try to find the phase which fits best to the concept of Maven2. This is important if other developers try to find out what is happening in the hole lifecycle.

We often use the AntRun-Plugin because it is a very easy way, to copy things, move things around or include tasks where you don’t want to write your own plugin. See an example for including this in your lifecycle:

...
  
    
      
        maven-antrun-plugin
        
          
            Deploy .war
            install
            
              
                
              
            
            
              run
            
          
        
      
    
  

...

In the next example you will see, how to start an integration test:

...
    
        ostium-mobile-suite
        
            
                maven-compiler-plugin
                
                    1.5
                    1.5
                    UTF-8
                
            
            
                org.codehaus.cargo
                cargo-maven2-plugin
                0.3-SNAPSHOT
                
                    false
                    
                        tomcat5x
                        
                            http://www.apache.org/dist/tomcat/tomcat-5/v5.5.16/bin/apache-tomcat-5.5.16.zip
                        
                        ${project.build.directory}/tomcat5x.log
                        ${project.build.directory}/cargo.log
                    
                    
                        ${project.build.directory}/tomcat5x/container
                        
                            high
                            8080
                            mobile:mobile:agent
                        
                    

                
                
                    
                        start-container
                        pre-integration-test
                        
                            start
                            deploy
                        
                        
                            
                                
                                    
                                        agimatec
                                        mobile-suite

                                        war
                                        http://localhost:8080/ostium-mobile-suite/menu/index.action
                                        
                                        300000
                                        
                                            ostium-mobile-suite
                                        
                                    

                                
                            
                        
                    
                    
                        stop-container
                        post-integration-test
                        
                            stop
                        
                    
                

            

            
                org.codehaus.mojo
                selenium-maven-plugin

                
                    
                        pre-integration-test
                        
                            start-server
                        
                        
                            true
                        
                    
                
            

            
                org.apache.maven.plugins
                maven-surefire-plugin

                
                    true
                

                
                    
                        integration-test
                        
                            test
                        
                        
                            false
                        
                    
                
            
        
    
...

To explore more details of the lifecycle phases read the Maven2 documentation.