junit

JUnit is a unit testing framework for the Java programming language. JUnit has been important in the development of test-driven development, and is one of a family of unit testing frameworks which is collectively known as xUnit that originated with SUnit. read more at WikiPedia

  • In computer programming, a unit test is a method of testing the correctness of a particular module of source code. The idea is to write test cases for every non-trivial function or method in the module so that each test case is separate from the others if possible.

    JUNIT: A testcase framework for Java

     

    In computer programming, a unit test is a method of testing the correctness of a particular module of source code. The idea is to write test cases for every non-trivial function or method in the module so that each test case is separate from the others if possible.

    Advantages
    The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. It provides a written contract that the piece must satisfy. This isolated testing provides two main benefits:

    • Encourages change
      Unit testing allows the programmer to refactor code at a later date, and make sure the module still works correctly (regression testing). This provides the benefit of encouraging programmers to make changes to the code since it is easy for the programmer to check if the piece is still working properly.
    • Simplifies Integration
      Unit testing helps eliminate uncertainty in the pieces themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts will make integration testing easier.
    • Documentation
      As an added value, all your Testcases can act as a documentation for your set of classes

    Kent Beck, (CSLife) and Erich Gamma, (OTI Zürich) have made a very good article:
    "Testing is not closely integrated with development. This prevents you from measuring the progress of development- you can't tell when something starts working or when something stops working. Using JUnit you can cheaply and incrementally build a test suite that will help you measure your progress, spot unintended side effects, and focus your development efforts." more here

    Limitations
    It is important to realize that unit-testing will not catch every error in the program. By definition, it only tests the functionality of the units themselves. Therefore, it will not catch integration errors, performance problems and any other system-wide issues. Unit testing is only effective if it is used in conjunction with other software testing activities.

    Usage
    There is a lot of ways to use JUNIT:

    • Write your set of classes, then some Testcase that should run and validate the work done,
    • Write Testcases first that won't run because no classes are existing yet, then write the code that will make it run!
    • Correct a bug in a piece of code, and write a Testcase for being sure that it won't reappear one day.

    Junit is based on fact that you want to test a code. Normally you know the result expected, all you have to do is to ask your code (class, method, set of cooperating class) and to test if the response is correct.
    Let's take an example.... I have a Class that can replace patterns in a string (like in JDK 1.4.2: "aText".replace("seachPattern","withThisPattern"))). Since I wrote the class, and know the purpose of it, I can write some pertinent testcases. I want to protect this Object and all other Object that may use it from loss of functionnality, bugs which may lead to malfunction in a complex system.

    Writing good Testcases

    There is no rule how to write a test, but remember

    • That a testcase should be pertinent, otherwise it will have no quality impact and will lead to a loss of developer time.
    • Be honest: push your Objects to the limit of their usage! try to describe and test all functionnality of your set of objects.
    • You need to do some dummy/obvious assertions (but sometimes these dummy tests are not obvious with complex object and or runtime environment).
      Constructor should not give back the same instance
      (Except if you are using a singleton pattern)
      ClassA classA = new ClassA();
      ClassA classA1 = new ClassA();
      assertNotEquals(classA, classA1);
      

    The JUNIT language

    JUnit use some primitives methods to achieve regression testing. As today in JUNIT 1.3.8, The assertion methods are all located in junit.framework.AssertA lot of third party tools has been developed to extends possibilities of tests with database, EJB, JSP for example.

    • Assert methods are testing equality of nearly all Java standard type
    • If these methods are not enough, you can always decide to validate your objects by Your own and call fail() if you decide that conditions are not met.

    Write your first Testcase

    A Junit test is a classe which extends junit.framework.Tescase and has some methods beginning with the word "test"

    A trivial example:

    Your first JUNIT testcase classe
    public class SquareTest extends junit.framework.TestCase {
            public void testClassA {
            
             Square squareA = new Square();
             Square squareB = new Square();
            
             assertNotEquals(squareB,squareA);
             assertEquals(squareA.getName(),"ClassAadummyexample");
            
             //verifysetter,getter
             squareA.setX(2);assertEquals(2,squareA.getX());
             squareA.setY(4);assertEquals(4,squareA.getY());
            
             //perimeterofasquareis2X+2y
             assertEquals(12,squareA.getPerimeter());
             //surface
             assertEquals(8,squareA.getSurface());
            }
    
            public void testCloneability() {
            
             Square squareA = new Square();
             squareA.setX(10);
             
             Square squareB = (Square) squareA.clone();
            
             //ifSquaredonotimplemeentComparable,thefollowingistrue
             assertNotEquals(squareA,squareB);
             
             //testdeepClone
             assertEquals(10,squareB.getX());
            }
    }
    

    Writing a Testcase is always more or less the same:

    1. Create one or more classes extending junit.framework.Tescaseand implement some test methods
    2. Create in these methods instances of the object you want to test or validate.
    3. Use your object, use setter and getter, constructor to change their internal state (here is the concept of pushing your object to the limits: use the full range of input data accepted by your objects)
    4. Test values returned by methods, assuming that you know what would be the correct result,
    5. Write a lot of them to test the maximum of functionnalities provided by your objects.

    Run your testcases
    Different TestRunner or how to run your suite of testcases

    A TestRunner is able to run JUNIT testcases, there is more or less 2 categories:

    • Textual TestRunner (console output)
      • The fastest to launch and can be used when you don't need a red green success indication. This is recommended with ANT.
    • Graphical TestRunners (client server web GUI, swing, AWT in eclipse....)
      • They show a simple graphical dialog to start/stop and display results of tests and provide some graphical progress indication.

    A TestRunner can be configured to be either loading or non-loading. In the loading configuration the TestRunner reloads your class from the class path for each run. As a consequence you don't have to restart the TestRunner after you have changed your code. In the non-loading configuration you have to restart the TestRunner after each run. The TestRunner configuration can be either set on the command line with the -noloading switch or in the junit.properties file located in the "user.home" by adding an entry loading=false.

    JUNIT find all testcase using java.lang.reflexion package, in fact it will call all methods starting with the word test will be found.

    In a JAVA main class:
    String[] listUnitTest = {ClassA.class.getName(), ClassB.class.getName()}; //list of classname containing your units tests
    junit.textui.TestRunner.main(listUnitTest); //Text based
    junit.awtui.TestRunner.main(listUnitTest);//green mean all test successful red is bad in case of error, you see the stack and which test failed.
    junit.swingui.TestRunner.main(listUnitTest); //green mean all testcases successful red is badin case of error, you see the stack and which test failed.
    JUnit Testrunner in Eclipse is a standar View

    Testsuite
    Testsuite is a suite of testcase or method, you can give this testsuite to a testrunner.

    Some particular TestSuite

    Multi threading test
    If you need to have multiple threads hitting your class. ActiveTestSuite starts each test in its own thread However, ActiveTestSuite does not have a constructor which automatically adds all testXXX methods in a class to the test suite. I tried addTestSuite method with class name as the argument, but it added all tests in the class to run sequentially in the same thread. So, I had to manually add each test name to the ActiveTestSuite.
    public static Test suite() {
    TestSuite suite = new ActiveTestSuite();
    suite.addTest(new com.waltercedric.junit.ClassA ("testClonability"));
    suite.addTest(new com.waltercedric.junit.ClassA ("testSerialization"));
    suite.addTest(new com.waltercedric.junit.ClassA ("testRandom"));
    return suite;
    }

    public static void runTest (String[] args) {
    junit.textui.TestRunner.run( suite() );
    }

    Extensions
    JUNIT can be extended with 3rd party extensions, if you need some specials capabilities, refer to this page: JUNIT extensions

     

  • Still hesitating about using or not using regression tests in your code? (JUNIT for java for ex.) Look here at Failed fixes haunt credibility of Microsoft's Trustworthy Computing Initiative. Even Microsoft has some problem today...because they do not have invested enough time/money/power into it....

  • open.qa.logo
    Selenium is a test tool for web applications. Selenium tests run directly in a browser, just like real users do. It runs in Internet Explorer, Mozilla and Firefox on Windows, Linux, and Macintosh, Safari on the Mac.  They have plans to target Safari on the iPhone in some months. The tool is free and available under Apache 2.0.
    Since I have clearly quality issues during the development/releasing of my components for Joomla!, I am trying now to use the same tooling I daily use in java EE solutions for PHP...In this series I will present you some ideas (Unit testing, Continuous integration, code quality) that you may want to put in use as well.

    The quickest way to learn Selenium is via a Firefox plugin called Selenium IDE. It is quite compelling
    for developing tests in and quickly trying out Selenium before choosing Selenium for your project.

    There are two modes of operation for Selenium - Coreand Remote Control (RC).  Remote Control
    mode also has a related capability called Selenium Grid that allows you to throw hardware at tests
    to make it all faster.

    This tools is able to:

    • Simulate any action a human user may do either with the help of the keyboard or the mouse,
      this go from entering a text to select values in select list.
    • These workflow can be save and replay at any time and any speed.
    • You may group a set of tests and form a test suite very easily.
    • Export tests to Ruby, Python, Perl, Java .Net to run them in a non graphical environment ().

     

    Selenium is made of 3 components:

    • Selenium Core : the core must be installed on your server where the web applications are running.
    • Selenium IDE : is a Firefox/IE/Mozilla extension Firefox able to record, execute tests and test suites
    • Selenium Remote Control is a server which let you execute tests targeting many different browser,
      Firefox, Internet Explorer, opera and different operating system GNU/Linux,Mac OS and  MS Windows
      in also many different languages Ruby, Python, Perl, Java .Net.

    Also don't use Selenium for load testing web applications!, use Apache JMETER  instead. Attention Selenium
    has some issues when he has to work on 2 windows at the same time (pop -up).

    Today let just try Selenium IDE

    To make it work with Joomla!, or with any other web applications, just install the Firefox plugins, and start
    it by going to the tools menu of Firefox.

    Lets say that we want to test the contact page of my site for proper operations...In Firefox, go to the menu Tools

    selenium1

    This will open a floating windows, which let you define a script step by step in the windows ff0000">Script

    You may come with a test case similar to the one presented here:

    selenium-joomla-test

    The number of commands is huge, but well documented in the tab reference (ff0000">B)

    The base URL is my site (http://www.waltercedric.com), the test case, open the contact page, check the
    title of the page, enter some values in form, check for button and texts and submit the form.

    The menu selenium2  let you run the test by clicking on selenium3 you can see the
    result, if everything is green then the test has succeed.

    selenium4

    and you see every step of the test case in the browser windows:

    selenium6 

    As you see it is quite easy to develop a script to test a page, test can be saved on disk  in different format,
    so you can execute them in Selenium Core

    selenium5

    So the test developed for testing the contact page of Joomla! now look like:

       1: package com.example.tests;
       2:  
       3: import com.thoughtworks.selenium.*;
       4: import java.util.regex.Pattern;
       5:  
       6: public class NewTest extends SeleneseTestCase {
       7:     public void setUp() throws Exception {
       8:         setUp("http://www.waltercedric.com/", "*chrome");
       9:     }
      10:     public void testNew() throws Exception {
      11:         // selenium.("http://www.waltercedric.com/-contact-me.html");
      12:         assertEquals("Contact - Cedric Walter", selenium.getTitle());
      13:         selenium.type("contact_name", "cedric");
     14:  selenium.type("contact_email", "This email address is being protected from spambots. You need JavaScript enabled to view it.");
      15:         selenium.type("contact_subject", "Selenium is great, try it");
      16:         verifyTrue(selenium.isTextPresent("Enter your Message:"));
      17:         selenium.type("contact_text", "Hi Cedric. selenium would be cool for testing securityimages!");
      18:         verifyTrue(selenium.isTextPresent("Send"));
      19:         selenium.submit("emailForm");
      20:         selenium.waitForPageToLoad("30000");
      21:     }
      22: }
    .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: 008000; } .csharpcode .kwrd { color: 0000ff; } .csharpcode .str { color: 006080; } .csharpcode .op { color: 0000c0; } .csharpcode .preproc { color: cc6633; } .csharpcode .asp { background-color: ffff00; } .csharpcode .html { color: 800000; } .csharpcode .attr { color: ff0000; } .csharpcode .alt { background-color: f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: 606060; }

    Or better in PHP so you can reuse it in XINC continuous integration server (more to come on XINC in a future article)

       1: <?php
       2:  
       3: require_once 'PHPUnit/Extensions/SeleniumTestCase.php';
       4:  
       5: class Example extends PHPUnit_Extensions_SeleniumTestCase
       6: {
       7:   function setUp()
       8:   {
       9:     $this->setBrowser("*chrome");
      10:     $this->setBrowserUrl("http://www.waltercedric.com/");
      11:   }
      12:  
      13:   function testMyTestCase()
      14:   {
      15:     // $this->("http://www.waltercedric.com/-contact-me.html");
      16:     $this->assertEquals("Contact - Cedric Walter", $this->getTitle());
      17:     $this->type("contact_name", "cedric");
     18:  $this->type("contact_email", "This email address is being protected from spambots. You need JavaScript enabled to view it.");
      19:     $this->type("contact_subject", "Selenium is great, try it");
      20:     try {
      21:         $this->assertTrue($this->isTextPresent("Enter your Message:"));
      22:     } catch (PHPUnit_Framework_AssertionFailedError $e) {
      23:         array_push($this->verificationErrors, $e->toString());
      24:     }
      25:     $this->type("contact_text", "Hi Cedric. selenium would be cool for testing securityimages!");
      26:     try {
      27:         $this->assertTrue($this->isTextPresent("Send"));
      28:     } catch (PHPUnit_Framework_AssertionFailedError $e) {
      29:         array_push($this->verificationErrors, $e->toString());
      30:     }
      31:     $this->submit("emailForm");
      32:     $this->waitForPageToLoad("30000");
      33:   }
      34: }
      35: ?>
    .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: 008000; } .csharpcode .kwrd { color: 0000ff; } .csharpcode .str { color: 006080; } .csharpcode .op { color: 0000c0; } .csharpcode .preproc { color: cc6633; } .csharpcode .asp { background-color: ffff00; } .csharpcode .html { color: 800000; } .csharpcode .attr { color: ff0000; } .csharpcode .alt { background-color: f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: 606060; }

    As soon as You have a set of tests, this can form a Test Suite.

    SecurityImages for Joomla create Captcha, so it is quite difficult for a tool to pass the Turin test
    (aka recognize the scrambled images), this point apart, I am now developing testcases to test the
    admin backend, frontend Joomla! patches. These test will be available in the component itself, so
    anybody can run them with little efforts.

    Read more at:

     


    ff0000">Here is the list of all commands, use search in page to quickly find the right command.

    addLocationStrategy ( strategyName,functionDefinition )
    Defines a new function for Selenium to locate elements on the page. For example, if you
    define the strategy "foo", and someone runs click("foo=blah"), we'll run your function, passing
    you the string "blah", and click on the element that your function returns, or throw an "Element
    not found" error if your function returns null. We'll pass three arguments to your function:
    • locator: the string the user passed in
    • inWindow: the currently selected window
    • inDocument: the currently selected document
    The function must return null if the element can't be found.

    Arguments:

    • strategyName - the name of the strategy to define; this should use only letters [a-zA-Z] with
    • no spaces or other punctuation.
    • functionDefinition - a string defining the body of a function in JavaScript. For example: return inDocument.getElementById(locator);

    addSelection ( locator,optionLocator )
    Add a selection to the set of selected options in a multi-select element using an option locator.
    @see doSelect for details of option locators

    Arguments:

    • locator - an element locator identifying a multi-select box
    • optionLocator - an option locator (a label by default)

    allowNativeXpath ( allow )
    Specifies whether Selenium should use the native in-browser implementation of XPath (if any native
    version is available); if you pass "false" to this function, we will always use our pure-JavaScript xpath
    library. Using the pure-JS xpath library can improve the consistency of xpath element locators
    between different browser vendors, but the pure-JS version is much slower than the native implementations.

    Arguments:

    • allow - boolean, true means we'll prefer to use native XPath; false means we'll only use JS XPath

    altKeyDown ( )
    Press the alt key and hold it down until doAltUp() is called or a new page is loaded.
    altKeyUp ( )
    Release the alt key.
    answerOnNextPrompt ( answer )
    Instructs Selenium to return the specified answer string in response to the next JavaScript
    prompt [window.prompt()].

    Arguments:

    • answer - the answer to give in response to the prompt pop-up

    assignId ( locator,identifier )
    Temporarily sets the "id" attribute of the specified element, so you can locate it in the
    future using its ID rather than a slow/complicated XPath. This ID will disappear once the page is reloaded.

    Arguments:

    • locator - an element locator pointing to an element
    • identifier - a string to be used as the ID of the specified element

    break ( )
    Halt the currently running test, and wait for the user to press the Continue button. This command
    is useful for debugging, but be careful when using it, because it will force automated tests to hang
    until a user intervenes manually.
    captureEntirePageScreenshot ( filename )
    Saves the entire contents of the current window canvas to a PNG file. Currently this only works in
    Mozilla and when running in chrome mode. Contrast this with the captureScreenshot command,
    which captures the contents of the OS viewport (i.e. whatever is currently being displayed on
    the monitor), and is implemented in the RC only. Implementation mostly borrowed from the
    Screengrab! Firefox extension. Please see http://www.screengrab.org for details.

    Arguments:

    • filename - the path to the file to persist the screenshot as. No filename extension will be appended by default. Directories will not be created if they do not exist, and an exception will be thrown, possibly by native code.

    check ( locator )
    Check a toggle-button (checkbox/radio)

    Arguments:


    chooseCancelOnNextConfirmation ( )
    By default, Selenium's overridden window.confirm() function will return true, as if the user had manually clicked OK; after running this command, the next call to confirm() will return false, as if the user had clicked Cancel. Selenium will then resume using the default behavior for future confirmations, automatically returning true (OK) unless/until you explicitly call this command for each confirmation.
    chooseOkOnNextConfirmation ( )
    Undo the effect of calling chooseCancelOnNextConfirmation. Note that Selenium's overridden window.confirm() function will normally automatically return true, as if the user had manually clicked OK, so you shouldn't need to use this command unless for some reason you need to change your mind prior to the next confirmation. After any confirmation, Selenium will resume using the default behavior for future confirmations, automatically returning true (OK) unless/until you explicitly call chooseCancelOnNextConfirmation for each confirmation.
    click ( locator )
    Clicks on a link, button, checkbox or radio button. If the click action causes a new page to load (like a link usually does), call waitForPageToLoad.

    Arguments:

    • locator - an element locator

    clickAt ( locator,coordString )
    Clicks on a link, button, checkbox or radio button. If the click action causes a new page to load (like a link usually does), call waitForPageToLoad.

    Arguments:

    • locator - an element locator
    • coordString - specifies the x,y position (i.e. - 10,20) of the mouse event relative to the element returned by the locator.

    close ( )
    Simulates the user clicking the "close" button in the titlebar of a popup window or tab.
    contextMenu ( locator )
    Simulates opening the context menu for the specified element (as might happen if the user "right-clicked" on the element).

    Arguments:

    • locator - an element locator

    contextMenuAt ( locator,coordString )
    Simulates opening the context menu for the specified element (as might happen if the user "right-clicked" on the element).

    Arguments:

    • locator - an element locator
    • coordString - specifies the x,y position (i.e. - 10,20) of the mouse event relative to the element returned by the locator.

    controlKeyDown ( )
    Press the control key and hold it down until doControlUp() is called or a new page is loaded.
    controlKeyUp ( )
    Release the control key.
    createCookie ( nameValuePair,optionsString )
    Create a new cookie whose path and domain are same with those of current page under test, unless you specified a path for this cookie explicitly.

    Arguments:

    • nameValuePair - name and value of the cookie in a format "name=value"
    • optionsString - options for the cookie. Currently supported options include 'path', 'max_age' and 'domain'. the optionsString's format is "path=/path/, max_age=60, domain=.foo.com". The order of options are irrelevant, the unit of the value of 'max_age' is second. Note that specifying a domain that isn't a subset of the current domain will usually fail.

    deleteAllVisibleCookies ( )
    Calls deleteCookie with recurse=true on all cookies visible to the current page. As noted on the documentation for deleteCookie, recurse=true can be much slower than simply deleting the cookies using a known domain/path.
    deleteCookie ( name,optionsString )
    Delete a named cookie with specified path and domain. Be careful; to delete a cookie, you need to delete it using the exact same path and domain that were used to create the cookie. If the path is wrong, or the domain is wrong, the cookie simply won't be deleted. Also note that specifying a domain that isn't a subset of the current domain will usually fail. Since there's no way to discover at runtime the original path and domain of a given cookie, we've added an option called 'recurse' to try all sub-domains of the current domain with all paths that are a subset of the current path. Beware; this option can be slow. In big-O notation, it operates in O(n*m) time, where n is the number of dots in the domain name and m is the number of slashes in the path.

    Arguments:

    • name - the name of the cookie to be deleted
    • optionsString - options for the cookie. Currently supported options include 'path', 'domain' and 'recurse.' The optionsString's format is "path=/path/, domain=.foo.com, recurse=true". The order of options are irrelevant. Note that specifying a domain that isn't a subset of the current domain will usually fail.

    doubleClick ( locator )
    Double clicks on a link, button, checkbox or radio button. If the double click action causes a new page to load (like a link usually does), call waitForPageToLoad.

    Arguments:

    • locator - an element locator

    doubleClickAt ( locator,coordString )
    Doubleclicks on a link, button, checkbox or radio button. If the action causes a new page to load (like a link usually does), call waitForPageToLoad.

    Arguments:

    • locator - an element locator
    • coordString - specifies the x,y position (i.e. - 10,20) of the mouse event relative to the element returned by the locator.

    dragAndDrop ( locator,movementsString )
    Drags an element a certain distance and then drops it

    Arguments:

    • locator - an element locator
    • movementsString - offset in pixels from the current location to which the element should be moved, e.g., "+70,-300"

    dragAndDropToObject ( locatorOfObjectToBeDragged,locatorOfDragDestinationObject )
    Drags an element and drops it on another element

    Arguments:

    • locatorOfObjectToBeDragged - an element to be dragged
    • locatorOfDragDestinationObject - an element whose location (i.e., whose center-most pixel) will be the point where locatorOfObjectToBeDragged is dropped

    dragdrop ( locator,movementsString )
    deprecated - use dragAndDrop instead

    Arguments:

    • locator - an element locator
    • movementsString - offset in pixels from the current location to which the element should be moved, e.g., "+70,-300"

    echo ( message )
    Prints the specified message into the third table cell in your Selenese tables. Useful for debugging.

    Arguments:

    • message - the message to print

    fireEvent ( locator,eventName )
    Explicitly simulate an event, to trigger the corresponding "onevent" handler.

    Arguments:

    • locator - an element locator
    • eventName - the event name, e.g. "focus" or "blur"

    focus ( locator )
    Move the focus to the specified element; for example, if the element is an input field, move the cursor to that field.

    Arguments:


    goBack ( )
    Simulates the user clicking the "back" button on their browser.
    highlight ( locator )
    Briefly changes the backgroundColor of the specified element yellow. Useful for debugging.

    Arguments:


    ignoreAttributesWithoutValue ( ignore )
    Specifies whether Selenium will ignore xpath attributes that have no value, i.e. are the empty string, when using the non-native xpath evaluation engine. You'd want to do this for performance reasons in IE. However, this could break certain xpaths, for example an xpath that looks for an attribute whose value is NOT the empty string. The hope is that such xpaths are relatively rare, but the user should have the option of using them. Note that this only influences xpath evaluation when using the ajaxslt engine (i.e. not "javascript-xpath").

    Arguments:

    • ignore - boolean, true means we'll ignore attributes without value at the expense of xpath "correctness"; false means we'll sacrifice speed for correctness.

    keyDown ( locator,keySequence )
    Simulates a user pressing a key (without releasing it yet).

    Arguments:

    • locator - an element locator
    • keySequence - Either be a string("\" followed by the numeric keycode of the key to be pressed, normally the ASCII value of that key), or a single character. For example: "w", "\119".

    keyPress ( locator,keySequence )
    Simulates a user pressing and releasing a key.

    Arguments:

    • locator - an element locator
    • keySequence - Either be a string("\" followed by the numeric keycode of the key to be pressed, normally the ASCII value of that key), or a single character. For example: "w", "\119".

    keyUp ( locator,keySequence )
    Simulates a user releasing a key.

    Arguments:

    • locator - an element locator
    • keySequence - Either be a string("\" followed by the numeric keycode of the key to be pressed, normally the ASCII value of that key), or a single character. For example: "w", "\119".

    metaKeyDown ( )
    Press the meta key and hold it down until doMetaUp() is called or a new page is loaded.
    metaKeyUp ( )
    Release the meta key.
    mouseDown ( locator )
    Simulates a user pressing the mouse button (without releasing it yet) on the specified element.

    Arguments:


    mouseDownAt ( locator,coordString )
    Simulates a user pressing the mouse button (without releasing it yet) at the specified location.

    Arguments:

    • locator - an element locator
    • coordString - specifies the x,y position (i.e. - 10,20) of the mouse event relative to the element returned by the locator.

    mouseMove ( locator )
    Simulates a user pressing the mouse button (without releasing it yet) on the specified element.

    Arguments:


    mouseMoveAt ( locator,coordString )
    Simulates a user pressing the mouse button (without releasing it yet) on the specified element.

    Arguments:

    • locator - an element locator
    • coordString - specifies the x,y position (i.e. - 10,20) of the mouse event relative to the element returned by the locator.

    mouseOut ( locator )
    Simulates a user moving the mouse pointer away from the specified element.

    Arguments:


    mouseOver ( locator )
    Simulates a user hovering a mouse over the specified element.

    Arguments:


    mouseUp ( locator )
    Simulates the event that occurs when the user releases the mouse button (i.e., stops holding the button down) on the specified element.

    Arguments:


    mouseUpAt ( locator,coordString )
    Simulates the event that occurs when the user releases the mouse button (i.e., stops holding the button down) at the specified location.

    Arguments:

    • locator - an element locator
    • coordString - specifies the x,y position (i.e. - 10,20) of the mouse event relative to the element returned by the locator.

    open ( url )
    Opens an URL in the test frame. This accepts both relative and absolute URLs. The "open" command waits for the page to load before proceeding, ie. the "AndWait" suffix is implicit. Note: The URL must be on the same domain as the runner HTML due to security restrictions in the browser (Same Origin Policy). If you need to open an URL on another domain, use the Selenium Server to start a new browser session on that domain.

    Arguments:

    • url - the URL to open; may be relative or absolute

    openWindow ( url,windowID )
    Opens a popup window (if a window with that ID isn't already open). After opening the window, you'll need to select it using the selectWindow command.

    This command can also be a useful workaround for bug SEL-339. In some cases, Selenium will be unable to intercept a call to window.open (if the call occurs during or before the "onLoad" event, for example). In those cases, you can force Selenium to notice the open window's name by using the Selenium openWindow command, using an empty (blank) url, like this: openWindow("", "myFunnyWindow").

    Arguments:

    • url - the URL to open, which can be blank
    • windowID - the JavaScript window ID of the window to select

    pause ( waitTime )
    Wait for the specified amount of time (in milliseconds)

    Arguments:

    • waitTime - the amount of time to sleep (in milliseconds)

    refresh ( )
    Simulates the user clicking the "Refresh" button on their browser.
    removeAllSelections ( locator )
    Unselects all of the selected options in a multi-select element.

    Arguments:


    removeSelection ( locator,optionLocator )
    Remove a selection from the set of selected options in a multi-select element using an option locator. @see doSelect for details of option locators

    Arguments:

    • locator - an element locator identifying a multi-select box
    • optionLocator - an option locator (a label by default)

    runScript ( script )
    Creates a new "script" tag in the body of the current test window, and adds the specified text into the body of the command. Scripts run in this way can often be debugged more easily than scripts executed using Selenium's "getEval" command. Beware that JS exceptions thrown in these script tags aren't managed by Selenium, so you should probably wrap your script in try/catch blocks if there is any chance that the script will throw an exception.

    Arguments:

    • script - the JavaScript snippet to run

    select ( selectLocator,optionLocator )
    Select an option from a drop-down using an option locator.

    Option locators provide different ways of specifying options of an HTML Select element (e.g. for selecting a specific option, or for asserting that the selected option satisfies a specification). There are several forms of Select Option Locator.

    • label=labelPattern: matches options based on their labels, i.e. the visible text. (This is the default.)
      • label=regexp:^[Oo]ther
    • value=valuePattern: matches options based on their values.
      • value=other
    • id=id: matches options based on their ids.
      • id=option1
    • index=index: matches an option based on its index (offset from zero).
      • index=2

    If no option locator prefix is provided, the default behaviour is to match on label.

    Arguments:

    • selectLocator - an element locator identifying a drop-down menu
    • optionLocator - an option locator (a label by default)

    selectFrame ( locator )
    Selects a frame within the current window. (You may invoke this command multiple times to select nested frames.) To select the parent frame, use "relative=parent" as a locator; to select the top frame, use "relative=top". You can also select a frame by its 0-based index number; select the first frame with "index=0", or the third frame with "index=2".

    You may also use a DOM expression to identify the frame you want directly, like this: dom=frames["main"].frames["subframe"]

    Arguments:


    selectWindow ( windowID )
    Selects a popup window using a window locator; once a popup window has been selected, all commands go to that window. To select the main window again, use null as the target.

    Window locators provide different ways of specifying the window object: by title, by internal JavaScript "name," or by JavaScript variable.

    • title=My Special Window: Finds the window using the text that appears in the title bar. Be careful; two windows can share the same title. If that happens, this locator will just pick one.
    • name=myWindow: Finds the window using its internal JavaScript "name" property. This is the second parameter "windowName" passed to the JavaScript method window.open(url, windowName, windowFeatures, replaceFlag) (which Selenium intercepts).
    • var=variableName: Some pop-up windows are unnamed (anonymous), but are associated with a JavaScript variable name in the current application window, e.g. "window.foo = window.open(url);". In those cases, you can open the window using "var=foo".

    If no window locator prefix is provided, we'll try to guess what you mean like this:

    1.) if windowID is null, (or the string "null") then it is assumed the user is referring to the original window instantiated by the browser).

    2.) if the value of the "windowID" parameter is a JavaScript variable name in the current application window, then it is assumed that this variable contains the return value from a call to the JavaScript window.open() method.

    3.) Otherwise, selenium looks in a hash it maintains that maps string names to window "names".

    4.) If that fails, we'll try looping over all of the known windows to try to find the appropriate "title". Since "title" is not necessarily unique, this may have unexpected behavior.

    If you're having trouble figuring out the name of a window that you want to manipulate, look at the Selenium log messages which identify the names of windows created via window.open (and therefore intercepted by Selenium). You will see messages like the following for each window as it is opened:

    debug: window.open call intercepted; window ID (which you can use with selectWindow()) is "myNewWindow"

    In some cases, Selenium will be unable to intercept a call to window.open (if the call occurs during or before the "onLoad" event, for example). (This is bug SEL-339.) In those cases, you can force Selenium to notice the open window's name by using the Selenium openWindow command, using an empty (blank) url, like this: openWindow("", "myFunnyWindow").

    Arguments:

    • windowID - the JavaScript window ID of the window to select

    setBrowserLogLevel ( logLevel )
    Sets the threshold for browser-side logging messages; log messages beneath this threshold will be discarded. Valid logLevel strings are: "debug", "info", "warn", "error" or "off". To see the browser logs, you need to either show the log window in GUI mode, or enable browser-side logging in Selenium RC.

    Arguments:

    • logLevel - one of the following: "debug", "info", "warn", "error" or "off"

    setCursorPosition ( locator,position )
    Moves the text cursor to the specified position in the given input element or textarea. This method will fail if the specified element isn't an input element or textarea.

    Arguments:

    • locator - an element locator pointing to an input element or textarea
    • position - the numerical position of the cursor in the field; position should be 0 to move the position to the beginning of the field. You can also set the cursor to -1 to move it to the end of the field.

    setMouseSpeed ( pixels )
    Configure the number of pixels between "mousemove" events during dragAndDrop commands (default=10).

    Setting this value to 0 means that we'll send a "mousemove" event to every single pixel in between the start location and the end location; that can be very slow, and may cause some browsers to force the JavaScript to timeout.

    If the mouse speed is greater than the distance between the two dragged objects, we'll just send one "mousemove" at the start location and then one final one at the end location.

    Arguments:

    • pixels - the number of pixels between "mousemove" events

    setSpeed ( value )
    Set execution speed (i.e., set the millisecond length of a delay which will follow each selenium operation). By default, there is no such delay, i.e., the delay is 0 milliseconds.

    Arguments:

    • value - the number of milliseconds to pause after operation

    setTimeout ( timeout )
    Specifies the amount of time that Selenium will wait for actions to complete.

    Actions that require waiting include "open" and the "waitFor*" actions.

    The default timeout is 30 seconds.

    Arguments:

    • timeout - a timeout in milliseconds, after which the action will return with an error

    shiftKeyDown ( )
    Press the shift key and hold it down until doShiftUp() is called or a new page is loaded.
    shiftKeyUp ( )
    Release the shift key.
    store ( expression,variableName )
    This command is a synonym for storeExpression.

    Arguments:

    • expression - the value to store
    • variableName - the name of a variable in which the result is to be stored.

    submit ( formLocator )
    Submit the specified form. This is particularly useful for forms without submit buttons, e.g. single-input "Search" forms.

    Arguments:


    type ( locator,value )
    Sets the value of an input field, as though you typed it in.

    Can also be used to set the value of combo boxes, check boxes, etc. In these cases, value should be the value of the option selected, not the visible text.

    Arguments:


    typeKeys ( locator,value )
    Simulates keystroke events on the specified element, as though you typed the value key-by-key.

    This is a convenience method for calling keyDown, keyUp, keyPress for every character in the specified string; this is useful for dynamic UI widgets (like auto-completing combo boxes) that require explicit key events.

    Unlike the simple "type" command, which forces the specified value into the page directly, this command may or may not have any visible effect, even in cases where typing keys would normally have a visible effect. For example, if you use "typeKeys" on a form element, you may or may not see the results of what you typed in the field.

    In some cases, you may need to use the simple "type" command to set the value of the field and then the "typeKeys" command to send the keystroke events corresponding to what you just typed.

    Arguments:


    uncheck ( locator )
    Uncheck a toggle-button (checkbox/radio)

    Arguments:


    waitForCondition ( script,timeout )
    Runs the specified JavaScript snippet repeatedly until it evaluates to "true". The snippet may have multiple lines, but only the result of the last line will be considered.

    Note that, by default, the snippet will be run in the runner's test window, not in the window of your application. To get the window of your application, you can use the JavaScript snippet selenium.browserbot.getCurrentWindow(), and then run your JavaScript in there

    Arguments:

    • script - the JavaScript snippet to run
    • timeout - a timeout in milliseconds, after which this command will return with an error

    waitForFrameToLoad ( frameAddress,timeout )
    Waits for a new frame to load.

    Selenium constantly keeps track of new pages and frames loading, and sets a "newPageLoaded" flag when it first notices a page load.

    See waitForPageToLoad for more information.

    Arguments:

    • frameAddress - FrameAddress from the server side
    • timeout - a timeout in milliseconds, after which this command will return with an error

    waitForPageToLoad ( timeout )
    Waits for a new page to load.

    You can use this command instead of the "AndWait" suffixes, "clickAndWait", "selectAndWait", "typeAndWait" etc. (which are only available in the JS API).

    Selenium constantly keeps track of new pages loading, and sets a "newPageLoaded" flag when it first notices a page load. Running any other Selenium command after turns the flag to false. Hence, if you want to wait for a page to load, you must wait immediately after a Selenium command that caused a page-load.

    Arguments:

    • timeout - a timeout in milliseconds, after which this command will return with an error

    waitForPopUp ( windowID,timeout )
    Waits for a popup window to appear and load up.

    Arguments:

    • windowID - the JavaScript window "name" of the window that will appear (not the text of the title bar)
    • timeout - a timeout in milliseconds, after which the action will return with an error

    windowFocus ( )
    Gives focus to the currently selected window
    windowMaximize ( )
    Resize currently selected window to take up the entire screen

    Selenium Accessors

    assertErrorOnNext ( message )
    Tell Selenium to expect an error on the next command execution.

    Arguments:

    • message - The error message we should expect. This command will fail if the wrong error message appears.

    Related Assertions, automatically generated:

    • assertNotErrorOnNext ( message )
    • verifyErrorOnNext ( message )
    • verifyNotErrorOnNext ( message )
    • waitForErrorOnNext ( message )
    • waitForNotErrorOnNext ( message )

    assertFailureOnNext ( message )
    Tell Selenium to expect a failure on the next command execution.

    Arguments:

    • message - The failure message we should expect. This command will fail if the wrong failure message appears.

    Related Assertions, automatically generated:

    • assertNotFailureOnNext ( message )
    • verifyFailureOnNext ( message )
    • verifyNotFailureOnNext ( message )
    • waitForFailureOnNext ( message )
    • waitForNotFailureOnNext ( message )

    assertSelected ( selectLocator,optionLocator )
    Verifies that the selected option of a drop-down satisfies the optionSpecifier. Note that this command is deprecated; you should use assertSelectedLabel, assertSelectedValue, assertSelectedIndex, or assertSelectedId instead.

    See the select command for more information about option locators.

    Arguments:

    • selectLocator - an element locator identifying a drop-down menu
    • optionLocator - an option locator, typically just an option label (e.g. "John Smith")

    Related Assertions, automatically generated:

    • assertNotSelected ( selectLocator, optionLocator )
    • verifySelected ( selectLocator, optionLocator )
    • verifyNotSelected ( selectLocator, optionLocator )
    • waitForSelected ( selectLocator, optionLocator )
    • waitForNotSelected ( selectLocator, optionLocator )

    storeAlert ( variableName )
    Retrieves the message of a JavaScript alert generated during the previous action, or fail if there were no alerts.

    Getting an alert has the same effect as manually clicking OK. If an alert is generated but you do not get/verify it, the next Selenium action will fail.

    NOTE: under Selenium, JavaScript alerts will NOT pop up a visible alert dialog.

    NOTE: Selenium does NOT support JavaScript alerts that are generated in a page's onload() event handler. In this case a visible dialog WILL be generated and Selenium will hang until someone manually clicks OK.

    Returns:
    The message of the most recent JavaScript alert

    Related Assertions, automatically generated:


    storeAllButtons ( variableName )
    Returns the IDs of all buttons on the page.

    If a given button has no ID, it will appear as "" in this array.

    Returns:
    the IDs of all buttons on the page

    Related Assertions, automatically generated:


    storeAllFields ( variableName )
    Returns the IDs of all input fields on the page.

    If a given field has no ID, it will appear as "" in this array.

    Returns:
    the IDs of all field on the page

    Related Assertions, automatically generated:


    storeAllLinks ( variableName )
    Returns the IDs of all links on the page.

    If a given link has no ID, it will appear as "" in this array.

    Returns:
    the IDs of all links on the page

    Related Assertions, automatically generated:


    storeAllWindowIds ( variableName )
    Returns the IDs of all windows that the browser knows about.
    Returns:
    the IDs of all windows that the browser knows about.

    Related Assertions, automatically generated:


    storeAllWindowNames ( variableName )
    Returns the names of all windows that the browser knows about.
    Returns:
    the names of all windows that the browser knows about.

    Related Assertions, automatically generated:

    • assertAllWindowNames ( pattern )
    • assertNotAllWindowNames ( pattern )
    • verifyAllWindowNames ( pattern )
    • verifyNotAllWindowNames ( pattern )
    • waitForAllWindowNames ( pattern )
    • waitForNotAllWindowNames ( pattern )

    storeAllWindowTitles ( variableName )
    Returns the titles of all windows that the browser knows about.
    Returns:
    the titles of all windows that the browser knows about.

    Related Assertions, automatically generated:

    • assertAllWindowTitles ( pattern )
    • assertNotAllWindowTitles ( pattern )
    • verifyAllWindowTitles ( pattern )
    • verifyNotAllWindowTitles ( pattern )
    • waitForAllWindowTitles ( pattern )
    • waitForNotAllWindowTitles ( pattern )

    storeAttribute ( attributeLocator, variableName )
    Gets the value of an element attribute. The value of the attribute may differ across browsers (this is the case for the "style" attribute, for example).

    Arguments:

    • attributeLocator - an element locator followed by an @ sign and then the name of the attribute, e.g. "foo@bar"
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    the value of the specified attribute

    Related Assertions, automatically generated:

    • assertAttribute ( attributeLocator, pattern )
    • assertNotAttribute ( attributeLocator, pattern )
    • verifyAttribute ( attributeLocator, pattern )
    • verifyNotAttribute ( attributeLocator, pattern )
    • waitForAttribute ( attributeLocator, pattern )
    • waitForNotAttribute ( attributeLocator, pattern )

    storeAttributeFromAllWindows ( attributeName, variableName )
    Returns every instance of some attribute from all known windows.

    Arguments:

    • attributeName - name of an attribute on the windows
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    the set of values of this attribute from all known windows.

    Related Assertions, automatically generated:

    • assertAttributeFromAllWindows ( attributeName, pattern )
    • assertNotAttributeFromAllWindows ( attributeName, pattern )
    • verifyAttributeFromAllWindows ( attributeName, pattern )
    • verifyNotAttributeFromAllWindows ( attributeName, pattern )
    • waitForAttributeFromAllWindows ( attributeName, pattern )
    • waitForNotAttributeFromAllWindows ( attributeName, pattern )

    storeBodyText ( variableName )
    Gets the entire text of the page.
    Returns:
    the entire text of the page

    Related Assertions, automatically generated:


    storeConfirmation ( variableName )
    Retrieves the message of a JavaScript confirmation dialog generated during the previous action.

    By default, the confirm function will return true, having the same effect as manually clicking OK. This can be changed by prior execution of the chooseCancelOnNextConfirmation command. If an confirmation is generated but you do not get/verify it, the next Selenium action will fail.

    NOTE: under Selenium, JavaScript confirmations will NOT pop up a visible dialog.

    NOTE: Selenium does NOT support JavaScript confirmations that are generated in a page's onload() event handler. In this case a visible dialog WILL be generated and Selenium will hang until you manually click OK.

    Returns:
    the message of the most recent JavaScript confirmation dialog

    Related Assertions, automatically generated:


    storeCookie ( variableName )
    Return all cookies of the current page under test.
    Returns:
    all cookies of the current page under test

    Related Assertions, automatically generated:


    storeCookieByName ( name, variableName )
    Returns the value of the cookie with the specified name, or throws an error if the cookie is not present.

    Arguments:

    • name - the name of the cookie
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    the value of the cookie

    Related Assertions, automatically generated:

    • assertCookieByName ( name, pattern )
    • assertNotCookieByName ( name, pattern )
    • verifyCookieByName ( name, pattern )
    • verifyNotCookieByName ( name, pattern )
    • waitForCookieByName ( name, pattern )
    • waitForNotCookieByName ( name, pattern )

    storeCursorPosition ( locator, variableName )
    Retrieves the text cursor position in the given input element or textarea; beware, this may not work perfectly on all browsers.

    Specifically, if the cursor/selection has been cleared by JavaScript, this command will tend to return the position of the last location of the cursor, even though the cursor is now gone from the page. This is filed as SEL-243.

    This method will fail if the specified element isn't an input element or textarea, or there is no cursor in the element.

    Arguments:

    • locator - an element locator pointing to an input element or textarea
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    the numerical position of the cursor in the field

    Related Assertions, automatically generated:

    • assertCursorPosition ( locator, pattern )
    • assertNotCursorPosition ( locator, pattern )
    • verifyCursorPosition ( locator, pattern )
    • verifyNotCursorPosition ( locator, pattern )
    • waitForCursorPosition ( locator, pattern )
    • waitForNotCursorPosition ( locator, pattern )

    storeElementHeight ( locator, variableName )
    Retrieves the height of an element

    Arguments:

    • locator - an element locator pointing to an element
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    height of an element in pixels

    Related Assertions, automatically generated:

    • assertElementHeight ( locator, pattern )
    • assertNotElementHeight ( locator, pattern )
    • verifyElementHeight ( locator, pattern )
    • verifyNotElementHeight ( locator, pattern )
    • waitForElementHeight ( locator, pattern )
    • waitForNotElementHeight ( locator, pattern )

    storeElementIndex ( locator, variableName )
    Get the relative index of an element to its parent (starting from 0). The comment node and empty text node will be ignored.

    Arguments:

    • locator - an element locator pointing to an element
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    of relative index of the element to its parent (starting from 0)

    Related Assertions, automatically generated:

    • assertElementIndex ( locator, pattern )
    • assertNotElementIndex ( locator, pattern )
    • verifyElementIndex ( locator, pattern )
    • verifyNotElementIndex ( locator, pattern )
    • waitForElementIndex ( locator, pattern )
    • waitForNotElementIndex ( locator, pattern )

    storeElementPositionLeft ( locator, variableName )
    Retrieves the horizontal position of an element

    Arguments:

    • locator - an element locator pointing to an element OR an element itself
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    of pixels from the edge of the frame.

    Related Assertions, automatically generated:

    • assertElementPositionLeft ( locator, pattern )
    • assertNotElementPositionLeft ( locator, pattern )
    • verifyElementPositionLeft ( locator, pattern )
    • verifyNotElementPositionLeft ( locator, pattern )
    • waitForElementPositionLeft ( locator, pattern )
    • waitForNotElementPositionLeft ( locator, pattern )

    storeElementPositionTop ( locator, variableName )
    Retrieves the vertical position of an element

    Arguments:

    • locator - an element locator pointing to an element OR an element itself
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    of pixels from the edge of the frame.

    Related Assertions, automatically generated:

    • assertElementPositionTop ( locator, pattern )
    • assertNotElementPositionTop ( locator, pattern )
    • verifyElementPositionTop ( locator, pattern )
    • verifyNotElementPositionTop ( locator, pattern )
    • waitForElementPositionTop ( locator, pattern )
    • waitForNotElementPositionTop ( locator, pattern )

    storeElementWidth ( locator, variableName )
    Retrieves the width of an element

    Arguments:

    • locator - an element locator pointing to an element
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    width of an element in pixels

    Related Assertions, automatically generated:

    • assertElementWidth ( locator, pattern )
    • assertNotElementWidth ( locator, pattern )
    • verifyElementWidth ( locator, pattern )
    • verifyNotElementWidth ( locator, pattern )
    • waitForElementWidth ( locator, pattern )
    • waitForNotElementWidth ( locator, pattern )

    storeEval ( script, variableName )
    Gets the result of evaluating the specified JavaScript snippet. The snippet may have multiple lines, but only the result of the last line will be returned.

    Note that, by default, the snippet will run in the context of the "selenium" object itself, so this will refer to the Selenium object. Use window to refer to the window of your application, e.g. window.document.getElementById('foo')

    If you need to use a locator to refer to a single element in your application page, you can use this.browserbot.findElement("id=foo") where "id=foo" is your locator.

    Arguments:

    • script - the JavaScript snippet to run
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    the results of evaluating the snippet

    Related Assertions, automatically generated:


    storeExpression ( expression, variableName )
    Returns the specified expression.

    This is useful because of JavaScript preprocessing. It is used to generate commands like assertExpression and waitForExpression.

    Arguments:

    • expression - the value to return
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    the value passed in

    Related Assertions, automatically generated:

    • assertExpression ( expression, pattern )
    • assertNotExpression ( expression, pattern )
    • verifyExpression ( expression, pattern )
    • verifyNotExpression ( expression, pattern )
    • waitForExpression ( expression, pattern )
    • waitForNotExpression ( expression, pattern )

    storeHtmlSource ( variableName )
    Returns the entire HTML source between the opening and closing "html" tags.
    Returns:
    the entire HTML source

    Related Assertions, automatically generated:


    storeLocation ( variableName )
    Gets the absolute URL of the current page.
    Returns:
    the absolute URL of the current page

    Related Assertions, automatically generated:


    storeMouseSpeed ( variableName )
    Returns the number of pixels between "mousemove" events during dragAndDrop commands (default=10).
    Returns:
    the number of pixels between "mousemove" events during dragAndDrop commands (default=10)

    Related Assertions, automatically generated:


    storePrompt ( variableName )
    Retrieves the message of a JavaScript question prompt dialog generated during the previous action.

    Successful handling of the prompt requires prior execution of the answerOnNextPrompt command. If a prompt is generated but you do not get/verify it, the next Selenium action will fail.

    NOTE: under Selenium, JavaScript prompts will NOT pop up a visible dialog.

    NOTE: Selenium does NOT support JavaScript prompts that are generated in a page's onload() event handler. In this case a visible dialog WILL be generated and Selenium will hang until someone manually clicks OK.

    Returns:
    the message of the most recent JavaScript question prompt

    Related Assertions, automatically generated:


    storeSelectedId ( selectLocator, variableName )
    Gets option element ID for selected option in the specified select element.

    Arguments:

    • selectLocator - an element locator identifying a drop-down menu
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    the selected option ID in the specified select drop-down

    Related Assertions, automatically generated:

    • assertSelectedId ( selectLocator, pattern )
    • assertNotSelectedId ( selectLocator, pattern )
    • verifySelectedId ( selectLocator, pattern )
    • verifyNotSelectedId ( selectLocator, pattern )
    • waitForSelectedId ( selectLocator, pattern )
    • waitForNotSelectedId ( selectLocator, pattern )

    storeSelectedIds ( selectLocator, variableName )
    Gets all option element IDs for selected options in the specified select or multi-select element.

    Arguments:

    • selectLocator - an element locator identifying a drop-down menu
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    an array of all selected option IDs in the specified select drop-down

    Related Assertions, automatically generated:

    • assertSelectedIds ( selectLocator, pattern )
    • assertNotSelectedIds ( selectLocator, pattern )
    • verifySelectedIds ( selectLocator, pattern )
    • verifyNotSelectedIds ( selectLocator, pattern )
    • waitForSelectedIds ( selectLocator, pattern )
    • waitForNotSelectedIds ( selectLocator, pattern )

    storeSelectedIndex ( selectLocator, variableName )
    Gets option index (option number, starting at 0) for selected option in the specified select element.

    Arguments:

    • selectLocator - an element locator identifying a drop-down menu
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    the selected option index in the specified select drop-down

    Related Assertions, automatically generated:

    • assertSelectedIndex ( selectLocator, pattern )
    • assertNotSelectedIndex ( selectLocator, pattern )
    • verifySelectedIndex ( selectLocator, pattern )
    • verifyNotSelectedIndex ( selectLocator, pattern )
    • waitForSelectedIndex ( selectLocator, pattern )
    • waitForNotSelectedIndex ( selectLocator, pattern )

    storeSelectedIndexes ( selectLocator, variableName )
    Gets all option indexes (option number, starting at 0) for selected options in the specified select or multi-select element.

    Arguments:

    • selectLocator - an element locator identifying a drop-down menu
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    an array of all selected option indexes in the specified select drop-down

    Related Assertions, automatically generated:

    • assertSelectedIndexes ( selectLocator, pattern )
    • assertNotSelectedIndexes ( selectLocator, pattern )
    • verifySelectedIndexes ( selectLocator, pattern )
    • verifyNotSelectedIndexes ( selectLocator, pattern )
    • waitForSelectedIndexes ( selectLocator, pattern )
    • waitForNotSelectedIndexes ( selectLocator, pattern )

    storeSelectedLabel ( selectLocator, variableName )
    Gets option label (visible text) for selected option in the specified select element.

    Arguments:

    • selectLocator - an element locator identifying a drop-down menu
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    the selected option label in the specified select drop-down

    Related Assertions, automatically generated:

    • assertSelectedLabel ( selectLocator, pattern )
    • assertNotSelectedLabel ( selectLocator, pattern )
    • verifySelectedLabel ( selectLocator, pattern )
    • verifyNotSelectedLabel ( selectLocator, pattern )
    • waitForSelectedLabel ( selectLocator, pattern )
    • waitForNotSelectedLabel ( selectLocator, pattern )

    storeSelectedLabels ( selectLocator, variableName )
    Gets all option labels (visible text) for selected options in the specified select or multi-select element.

    Arguments:

    • selectLocator - an element locator identifying a drop-down menu
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    an array of all selected option labels in the specified select drop-down

    Related Assertions, automatically generated:

    • assertSelectedLabels ( selectLocator, pattern )
    • assertNotSelectedLabels ( selectLocator, pattern )
    • verifySelectedLabels ( selectLocator, pattern )
    • verifyNotSelectedLabels ( selectLocator, pattern )
    • waitForSelectedLabels ( selectLocator, pattern )
    • waitForNotSelectedLabels ( selectLocator, pattern )

    storeSelectedValue ( selectLocator, variableName )
    Gets option value (value attribute) for selected option in the specified select element.

    Arguments:

    • selectLocator - an element locator identifying a drop-down menu
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    the selected option value in the specified select drop-down

    Related Assertions, automatically generated:

    • assertSelectedValue ( selectLocator, pattern )
    • assertNotSelectedValue ( selectLocator, pattern )
    • verifySelectedValue ( selectLocator, pattern )
    • verifyNotSelectedValue ( selectLocator, pattern )
    • waitForSelectedValue ( selectLocator, pattern )
    • waitForNotSelectedValue ( selectLocator, pattern )

    storeSelectedValues ( selectLocator, variableName )
    Gets all option values (value attributes) for selected options in the specified select or multi-select element.

    Arguments:

    • selectLocator - an element locator identifying a drop-down menu
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    an array of all selected option values in the specified select drop-down

    Related Assertions, automatically generated:

    • assertSelectedValues ( selectLocator, pattern )
    • assertNotSelectedValues ( selectLocator, pattern )
    • verifySelectedValues ( selectLocator, pattern )
    • verifyNotSelectedValues ( selectLocator, pattern )
    • waitForSelectedValues ( selectLocator, pattern )
    • waitForNotSelectedValues ( selectLocator, pattern )

    storeSelectOptions ( selectLocator, variableName )
    Gets all option labels in the specified select drop-down.

    Arguments:

    • selectLocator - an element locator identifying a drop-down menu
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    an array of all option labels in the specified select drop-down

    Related Assertions, automatically generated:

    • assertSelectOptions ( selectLocator, pattern )
    • assertNotSelectOptions ( selectLocator, pattern )
    • verifySelectOptions ( selectLocator, pattern )
    • verifyNotSelectOptions ( selectLocator, pattern )
    • waitForSelectOptions ( selectLocator, pattern )
    • waitForNotSelectOptions ( selectLocator, pattern )

    storeSpeed ( variableName )
    Get execution speed (i.e., get the millisecond length of the delay following each selenium operation). By default, there is no such delay, i.e., the delay is 0 milliseconds. See also setSpeed.
    Returns:
    the execution speed in milliseconds.

    Related Assertions, automatically generated:


    storeTable ( tableCellAddress, variableName )
    Gets the text from a cell of a table. The cellAddress syntax tableLocator.row.column, where row and column start at 0.

    Arguments:

    • tableCellAddress - a cell address, e.g. "foo.1.4"
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    the text from the specified cell

    Related Assertions, automatically generated:

    • assertTable ( tableCellAddress, pattern )
    • assertNotTable ( tableCellAddress, pattern )
    • verifyTable ( tableCellAddress, pattern )
    • verifyNotTable ( tableCellAddress, pattern )
    • waitForTable ( tableCellAddress, pattern )
    • waitForNotTable ( tableCellAddress, pattern )

    storeText ( locator, variableName )
    Gets the text of an element. This works for any element that contains text. This command uses either the textContent (Mozilla-like browsers) or the innerText (IE-like browsers) of the element, which is the rendered text shown to the user.

    Arguments:

    Returns:
    the text of the element

    Related Assertions, automatically generated:


    storeTitle ( variableName )
    Gets the title of the current page.
    Returns:
    the title of the current page

    Related Assertions, automatically generated:


    storeValue ( locator, variableName )
    Gets the (whitespace-trimmed) value of an input field (or anything else with a value parameter). For checkbox/radio elements, the value will be "on" or "off" depending on whether the element is checked or not.

    Arguments:

    Returns:
    the element value, or "on/off" for checkbox/radio elements

    Related Assertions, automatically generated:

    • assertValue ( locator, pattern )
    • assertNotValue ( locator, pattern )
    • verifyValue ( locator, pattern )
    • verifyNotValue ( locator, pattern )
    • waitForValue ( locator, pattern )
    • waitForNotValue ( locator, pattern )

    storeWhetherThisFrameMatchFrameExpression ( currentFrameString, target, variableName )
    Determine whether current/locator identify the frame containing this running code.

    This is useful in proxy injection mode, where this code runs in every browser frame and window, and sometimes the selenium server needs to identify the "current" frame. In this case, when the test calls selectFrame, this routine is called for each frame to figure out which one has been selected. The selected frame will return true, while all others will return false.

    Arguments:

    • currentFrameString - starting frame
    • target - new frame (which might be relative to the current one)
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    true if the new frame is this code's window

    Related Assertions, automatically generated:

    • assertWhetherThisFrameMatchFrameExpression ( currentFrameString, target )
    • assertNotWhetherThisFrameMatchFrameExpression ( currentFrameString, target )
    • verifyWhetherThisFrameMatchFrameExpression ( currentFrameString, target )
    • verifyNotWhetherThisFrameMatchFrameExpression ( currentFrameString, target )
    • waitForWhetherThisFrameMatchFrameExpression ( currentFrameString, target )
    • waitForNotWhetherThisFrameMatchFrameExpression ( currentFrameString, target )

    storeWhetherThisWindowMatchWindowExpression ( currentWindowString, target, variableName )
    Determine whether currentWindowString plus target identify the window containing this running code.

    This is useful in proxy injection mode, where this code runs in every browser frame and window, and sometimes the selenium server needs to identify the "current" window. In this case, when the test calls selectWindow, this routine is called for each window to figure out which one has been selected. The selected window will return true, while all others will return false.

    Arguments:

    • currentWindowString - starting window
    • target - new window (which might be relative to the current one, e.g., "_parent")
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    true if the new window is this code's window

    Related Assertions, automatically generated:

    • assertWhetherThisWindowMatchWindowExpression ( currentWindowString, target )
    • assertNotWhetherThisWindowMatchWindowExpression ( currentWindowString, target )
    • verifyWhetherThisWindowMatchWindowExpression ( currentWindowString, target )
    • verifyNotWhetherThisWindowMatchWindowExpression ( currentWindowString, target )
    • waitForWhetherThisWindowMatchWindowExpression ( currentWindowString, target )
    • waitForNotWhetherThisWindowMatchWindowExpression ( currentWindowString, target )

    storeXpathCount ( xpath, variableName )
    Returns the number of nodes that match the specified xpath, eg. "//table" would give the number of tables.

    Arguments:

    • xpath - the xpath expression to evaluate. do NOT wrap this expression in a 'count()' function; we will do that for you.
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    the number of nodes that match the specified xpath

    Related Assertions, automatically generated:

    • assertXpathCount ( xpath, pattern )
    • assertNotXpathCount ( xpath, pattern )
    • verifyXpathCount ( xpath, pattern )
    • verifyNotXpathCount ( xpath, pattern )
    • waitForXpathCount ( xpath, pattern )
    • waitForNotXpathCount ( xpath, pattern )

    storeAlertPresent ( variableName )
    Has an alert occurred?

    This function never throws an exception

    Returns:
    true if there is an alert

    Related Assertions, automatically generated:

    • assertAlertPresent ( )
    • assertAlertNotPresent ( )
    • verifyAlertPresent ( )
    • verifyAlertNotPresent ( )
    • waitForAlertPresent ( )
    • waitForAlertNotPresent ( )

    storeChecked ( locator, variableName )
    Gets whether a toggle-button (checkbox/radio) is checked. Fails if the specified element doesn't exist or isn't a toggle-button.

    Arguments:

    • locator - an element locator pointing to a checkbox or radio button
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    true if the checkbox is checked, false otherwise

    Related Assertions, automatically generated:

    • assertChecked ( locator )
    • assertNotChecked ( locator )
    • verifyChecked ( locator )
    • verifyNotChecked ( locator )
    • waitForChecked ( locator )
    • waitForNotChecked ( locator )

    storeConfirmationPresent ( variableName )
    Has confirm() been called?

    This function never throws an exception

    Returns:
    true if there is a pending confirmation

    Related Assertions, automatically generated:

    • assertConfirmationPresent ( )
    • assertConfirmationNotPresent ( )
    • verifyConfirmationPresent ( )
    • verifyConfirmationNotPresent ( )
    • waitForConfirmationPresent ( )
    • waitForConfirmationNotPresent ( )

    storeCookiePresent ( name, variableName )
    Returns true if a cookie with the specified name is present, or false otherwise.

    Arguments:

    • name - the name of the cookie
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    true if a cookie with the specified name is present, or false otherwise.

    Related Assertions, automatically generated:

    • assertCookiePresent ( name )
    • assertCookieNotPresent ( name )
    • verifyCookiePresent ( name )
    • verifyCookieNotPresent ( name )
    • waitForCookiePresent ( name )
    • waitForCookieNotPresent ( name )

    storeEditable ( locator, variableName )
    Determines whether the specified input element is editable, ie hasn't been disabled. This method will fail if the specified element isn't an input element.

    Arguments:

    Returns:
    true if the input element is editable, false otherwise

    Related Assertions, automatically generated:

    • assertEditable ( locator )
    • assertNotEditable ( locator )
    • verifyEditable ( locator )
    • verifyNotEditable ( locator )
    • waitForEditable ( locator )
    • waitForNotEditable ( locator )

    storeElementPresent ( locator, variableName )
    Verifies that the specified element is somewhere on the page.

    Arguments:

    Returns:
    true if the element is present, false otherwise

    Related Assertions, automatically generated:

    • assertElementPresent ( locator )
    • assertElementNotPresent ( locator )
    • verifyElementPresent ( locator )
    • verifyElementNotPresent ( locator )
    • waitForElementPresent ( locator )
    • waitForElementNotPresent ( locator )

    storeOrdered ( locator1, locator2, variableName )
    Check if these two elements have same parent and are ordered siblings in the DOM. Two same elements will not be considered ordered.

    Arguments:

    • locator1 - an element locator pointing to the first element
    • locator2 - an element locator pointing to the second element
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    true if element1 is the previous sibling of element2, false otherwise

    Related Assertions, automatically generated:

    • assertOrdered ( locator1, locator2 )
    • assertNotOrdered ( locator1, locator2 )
    • verifyOrdered ( locator1, locator2 )
    • verifyNotOrdered ( locator1, locator2 )
    • waitForOrdered ( locator1, locator2 )
    • waitForNotOrdered ( locator1, locator2 )

    storePromptPresent ( variableName )
    Has a prompt occurred?

    This function never throws an exception

    Returns:
    true if there is a pending prompt

    Related Assertions, automatically generated:

    • assertPromptPresent ( )
    • assertPromptNotPresent ( )
    • verifyPromptPresent ( )
    • verifyPromptNotPresent ( )
    • waitForPromptPresent ( )
    • waitForPromptNotPresent ( )

    storeSomethingSelected ( selectLocator, variableName )
    Determines whether some option in a drop-down menu is selected.

    Arguments:

    • selectLocator - an element locator identifying a drop-down menu
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    true if some option has been selected, false otherwise

    Related Assertions, automatically generated:

    • assertSomethingSelected ( selectLocator )
    • assertNotSomethingSelected ( selectLocator )
    • verifySomethingSelected ( selectLocator )
    • verifyNotSomethingSelected ( selectLocator )
    • waitForSomethingSelected ( selectLocator )
    • waitForNotSomethingSelected ( selectLocator )

    storeTextPresent ( pattern, variableName )
    Verifies that the specified text pattern appears somewhere on the rendered page shown to the user.

    Arguments:

    • pattern - a pattern to match with the text of the page
    • variableName - the name of a variable in which the result is to be stored.
    Returns:
    true if the pattern matches the text, false otherwise

    Related Assertions, automatically generated:

    • assertTextPresent ( pattern )
    • assertTextNotPresent ( pattern )
    • verifyTextPresent ( pattern )
    • verifyTextNotPresent ( pattern )
    • waitForTextPresent ( pattern )
    • waitForTextNotPresent ( pattern )

    storeVisible ( locator, variableName )
    Determines if the specified element is visible. An element can be rendered invisible by setting the CSS "visibility" property to "hidden", or the "display" property to "none", either for the element itself or one if its ancestors. This method will fail if the element is not present.

    Arguments:

    Returns:
    true if the specified element is visible, false otherwise

    Related Assertions, automatically generated:

    • assertVisible ( locator )
    • assertNotVisible ( locator )
    • verifyVisible ( locator )
    • verifyNotVisible ( locator )
    • waitForVisible ( locator )
    • waitForNotVisible ( locator )
  • In this article, an excerpt from Test-Driven Development: A J2EE Example (Apress, 2004), author Thomas Hammell helps you select the right tools for getting started with test-driven development (TDD)
    ...
    Following the Keep It Simple, Stupid (KISS) and You Aren't Gonna Need It (YAGNI) rules of extreme programming (XP), each tool listed in the following sections fits into the TDD process...
    more Here
  • Open-sourceITP - Powerful web application tester

    ITP is a deceptively simple, yet powerful web testing harness. It is a stand-alone Java application that can test your website from a user's perspective. It is amazingly simple and lightweight, yet can be used for powerful test-scripting by using building blocks to create large test runs.
    ITP is the fastest test harness software to learn. A test script is simply made up out of a few lines of XML. There is no programming involved! You will be testing your application in seconds.

  •  apache_maven

    The last year, I was at Jazoon 08, and I forget to tell you how good some of their presentation about Maven were

    Let the Continuous Build Embrace Your Database

    "JUnit tests should not depend on database state." - "Set up your test data before you run your test." - We figure this just does not always scale. Mocking test data for hundreds of tables may not be suitable and database schemes evolve as the application does.
    These are common challenges when developing large J2EE systems. This presentation shows practical approaches for project setups and (functional) tests that decided to depend on a database. Developers and build servers may or may not share the database and support for this should be as simple as possible. We give an overview of what proved to be a good setup for an Eclipse / Maven 2 based development and build environment that relies on an evolving relational schema.

    Read More Here 

    The PDF cannot be downloaded, fortunately  I‘ve made a backup just in case 2 years ago. I did upload the presentation at SlideShare

    Here is the mind map I’ve done during the presentation

    • Continuous build for DB
      • db changes
        • SQL script patches
        • changes in chema
        • different db state for  each trunk tag branches?
        • = hell of synchronization issues
        • they put script in SVN
        • only run modified scripts between each or last build
        • run SQL script against references db before pushing the same changes to prod
        • ex: developer commit, build server poll SVNand launch build, then propagate
        • they use continuum
      • they have made a framework that has some tables more to keep which files .SQL has run
      • and what .sql revision svn it was
      • so they can only run delta scripts
      • ex: version 1.0 in prod, but bug appear
        • -> open a branch
        • -> automatic run of branch sql scripts also to trunk
      • Idempotent
        • but the same script apply twice on different database status do not gibe the same result
          • so they have to make script idempotent by checking/handling all previous versions
        • views ad trigger can be Idempotent easily
      • they have DB quality checks
        • primary keys constraints
        • foreign keys
        • etc..
    • fightning bugs
      • not breaking sql scripts
      • no regressions
    • rerunnable junit functional tests
      • auto rollback junit class
        • their own impl of datasource
          • and connection
      • don’t expect developer to properly rollback called in teardown
      • extends autorollbackjunittestcase.class
      • autorollbacktestcase also existing in spring see spring-test.jar
    • eclipse maven setup
      • for junit tests
      • read junit.properties
      • if any junit-fritz.properties  exist it will use the user config file
        • good idea
        • the file will e committed but wont break continuum build server
      • multi modules
        • different classpath (test and main) between eclipse and maven
        • they use propertes in pom.xml and  variable in properties
          • -> filter
    • done by teslekurs
      • they have 70 modules
      • netcetera.ch
    • make a try
      • go to workspace in dos
        • run in pk common "mvn clean test" it should build common like in teamcity
      • Use spring test framework of spring 2.5
    • outlook
      • only oracle
      • they search good test data among their 1TB data
      • want to use maven in also in eclipse, they use the command line right now
    • ideas
      • they store the script they have run to create the database and their SVN revision in db

        someone in room has propose to keep the data in build and add a column to know if data was created by Junit or by the main code

     

    Database with junit

  • Official Novell Press release here, due mid april 2005
    • A complete Linux Operating System: SUSE LINUX OS built upon the Linux kernel 2.6.11,X.org 6.8.2
    • Multiple intuitive desktop environments: Latest KDE 3.4 and GNOME* 2.10,
    • A comprehensive set of Internet tools: Firefox* 1.0 Web browser; e-mail and instant messaging clients (supporting AOL, Yahoo!, MSN, Novell® GroupWise® Instant Messenger, and more),
    • A complete office suite: OpenOffice.org 2.0 (works with Microsoft* Office documents) ,
    • Leading graphics and multimedia applications: F-Spot photo organizer, the GIMP 2.2 and Inkscape graphics programs, multimedia viewers, CD/DVD burners and more,
    • Fully integrated system security: integrated firewall, spam blocker and virus scanner,
    • World class advanced networking services: Apache Web server, SAMBA, CUPS, DHCP, DNS and popular open source databases
    • Cutting edge new Mobility Support: Improved Wifi connections and Bluetooth devices, PDA and phone synchronization
    • Robust Virtualization: based on XEN (what is XEN?)
    • Voice over IP support
    • Multiple development Tools: Mono® ; KDevelop; Eclipse

    SUSE LINUX 9.3 Professional Review by Novell : not a very neutral review, but with some screenshots...
    Novell Packs Apps Into SuSE Linux 9.3 By David Worthington, BetaNews

     

  • apache_maven

    How to remote debug test cases

    Change the Team city project configuration by adding a -Dmaven.surefire.debug to Maven runner in Additional "Maven command line parameters"

    maven.remote.debug.testcases

    Now when test cases will be executed by maven surefire plugin, the build will wait for a remote debugging application to pick it up on port 5005 and this for EVERY MODULES
    meaning:  If you have 5 Maven modules (= java projects) with test cases maven surefire will request 5 times you to connect with remote debugging to your build server.

    Create a Remote Java Application launcher you'll also share in one eclipse project:

    maven.remote.debug.launcher

     

    Don't forget to remove the -D variable or your daily build may wait for a remote debug connection! or create a special build configuration of your project targeted for debugging purpose.

    Remote debugging Maven plugin

    put into "JVM command line parameters:" these settings:

    -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5006

    debug.maven.in.teamcity

    Create a Remote Java Application launcher you'll also share in one eclipse project that will connect to the port 5006.

  • section-java-testing.gifMost programmers do not write tests. We all know that we should write them, but for whatever reason, most of us don't. This is unfortunate, because testing is the most powerful tool we know of to improve software quality. Tests reduce bugs, provide accurate documentation, and improve design.

    Read the Top 12 Reasons why You must also try to convince your colleagues 

  • Beaucoup de personne me connaissant et qui m'écrivent me demande comment je developpe mes programmes java car je trouve toujours le moyen d'en faire des frameworks...ce qui est par définition plus dur.

    Eh bien j'applique plusieurs petite règles simples...

    1. Un bon tool: je ne travaille qu'avec eclipse (www.eclipse.org) car c'est un IDE de qualité et malgré la quantité de perspectives (j'en ai 16), views (j'en ai 64) et plugins (>20), je m'y sens à   l'aise. Je privilégie la vue hiérarchique "java browsing view" avec une vue supplementaire "hiérarchie" (F4) car cela facilite la navigation et le découpage sémantique losque je dévelope (projets<-> packages<->objets<->hiérarchie<->méthodes<->code)
    2. Un environnement de travail propice: Je travaille avec 2 écrans (un 21'' et un 15'4 LCD) car rien n'est plus ennuyeux de perdre son temps à   bouger/réduire/changer de tâches sans cesse. Cela me permet aussi de travailler en parallèle. C'est déroutant au début mais rien n'est plus malléable que le cerveau humain et vous vous surprendrez au bout de quelques semaines en passant d'un écran à   l'autre sans cesse. C'est simple si demain je trouve une méthode fiables et peu couteuse en temps CPU (pas avec une carte video USB svp) pour avoir un troisième écran, je saute sur l'occasion immédiatement.

    Ces 2 règles ne participent qu'a hauteur de 15% à   un travail de qualité...mais elle réduisent le stress au poste de travail. Le reste est plus standard...

    Quelques techniques de développement modernes, ont bouleversés ma vie (relativement courte) de developpeur:

    1. Les "design patterns" pour appliquer des élements d'architectures éprouvés à   des classes de problèmes.
      Il faut bien sur les comprendre (quand les appliquer et leurs bénéfices/inconvénients) sans pour autant savoir les implémenter. J'en place un maximum sans effort grà ¢ce à   un générateur de pattern (plugin eclipse).
      Je me débrouille pour avoir des hièrarchies la ou c'est évident (mais en général, elles apparaissent toute seule cf. Refactoring), j'ai rarement des super classes non abstraites et sans interface, je crée toujours des interfaces pour augmenter le niveau d'abstraction dans mon code à   chaque niveau (layer) et laisser à   l'utilisateur le droit d'insérer son code dans le mien.
      Rappeler vous: sans interfaces, vous n'avez pas de polymorphisme en java et un typage trop fort (pourquoi encore passer des types concrets à   vos objets alors que l'on peut jouer à   des niveaux plus abstraits avec les interfaces?)
      Les design patterns apportent, à   mon code, la flexibilité (pattern de créations), le dynamisme (pattern de comportements) ou améliore le design (pattern de structures)
      Je n'hésite pas non plus à   créer des objets en quantités et à   leur donner les droits et fonctions minimums qui leurs incombent, car peu m'inporte les pertes de performances: je privilégie le design quitte à   devoir profiler plus tard.
    2. Les "antipatterns" (www.antipatterns.com/) leur contraire, en général lorsque je récupère du code dans un mauvais état. Cela m'aide à   trouver quelle "design patterns" peut arranger la situation (en vue de la correction d'un bug, pour améliorer la maintenance etc...) 
    3. Je programme de plus en plus "par intentions" (lien-> informit), une idée centrale de l'extreme programming (XP voir  www.extremeprogramming.org ). Comment le client voudrait avoir à   utiliser mon code, en fait à   quoi doit ressembler idéalement le code (le nom des types, des méthodes, des mediateurs). Je les écrits (comme un squelette) et bien sur ils n'existent pas encore, (donc compile error). Je force donc eclipse à   les créer (Quick fix ou CTRL-1)  et remplis les blancs, à   savoir l'implémentation, ce qui est forcément une tache moins intéressante.

    4. l'UML (Unified Modelling Language) oui de plus en plus, mais uniquement pour observer l'évolution des dépendances entre les objects (les motifs et les relations) sur mon 2ème écran. Et toujours en reverse engineering: je modifie le code java et observe d'un oeil le diagramme UML. En fait cela rejoint la programmation par intention dans un sens sauf que normalement on part de l'UML par intention pour créer le squellete du code java et non l'inverse. Le sens que j'utilise permet cependant de compléter mon javadoc ou ma documentation efficacement.
    5. Les "metrics" (plugin eclipse metrics) ne me servent que rarement mais surtout pour auditter du code ne m'appartenant pas. J'utilise neanmoins le plugin Code analysys plugin(CAP) ou celui de IBM alphawork: Structural Analysis for Java (SA4j) néanmoins de temps en temps...

    Mais la véritable APOCALYPSE est survenue chez moi il y a trois ans:

    1. Avec le "Refactoring" ' www.refactoring.com ) il m'est impossible de tout prévoir et c'est la que trés rapidement, le refactoring tool de eclipse m'aide car j'itère des changes atomiques (dans le sens: élémentaire et rapide) très rapidement à   travers tout mon code et cela en permanence. Des méthodes bougent ou disparaissent, je renomme en permanence tout: variables, objects, packages (pour éviter des commentaires à   travers mon code). j'introduit aussi des design patterns.
      Je les utilisent tellement que j'ai définit des racourcis clavier dans le workspace de eclipse.
      Le code devient de plus en plus petit (donc moins de bugs/lignes) et fait de plus en plus de chose (par design). Il se bonnifie avec un risque minimum d'instabilité car
    2. J'utilise des "test unitaires" (Junit www.junit.org) qui m'assure aprés chaque gros refactoring que je n'ai pas perdu de fonctionnalitées, cela me sert aussi à   tester mes interfaces: comment mon code va ètre utilisé?, est ce que les signatures sont bien choisies? y a t'il assez de constructors et d'accessors, et sont t'il pertinents? La plupart du temps cela me force repasser par une étape de refactoring dans mon code.

    Est ce la bonne facon de developper? cela dépend des situations, du domaine ou vous travaillez et de vous bien sur.

    Est t'on forcément plus lent? oui et non, cette méthode est déroutante de prime abord mais elle respecte la théorie de l'évolution biologique, génération après génération (refactoring - design - refactoring - unit test) le code devient meilleur.

    Attention: on est pas forcément plus lent, mais cette méthode n'est pas très adaptée au problèmes pointues: on peut se prendre des murs sans cesse (et donc réimplémenter-refactorer) si on ne réflechit pas assez au préalable.

    D'un autre coté, ce qui est certain, c'est que écrire des frameworks est forcément plus long et plus dur que, en caricaturant, faire un main() de 150 lignes (mon dieu, cela se voit encore trop souvent). L'interèt de l'existence d'un framework est dans la réutilisation par d'autres personnes de votre code, et le fait que vous avez deja réalisés pour eux les taches les plus difficiles, mais tout en leur laissant la liberté de spécialiser votre code au besoin.

    Dans les composants java du coté serveur que je réalise pour l'ecommerce d'assurance vie, cela a toujours fonctionné. En tout cas pour moi....

  • Use JUNIT for

    • Designing/defining function.
    • Documentation: act like a sort of cookbook
    • Regression testing
    • You find a bug and correct it? write a JUNIT testcase! white paper available in download section
  • Bug Tracking Tool
    Work in progress

    or Why it is not possible to manage any software development without a bug tracking tool

    A bug tracking system is basically a database linked to  a frontend:
    • The frontend can be a FAT client, understand a windows or application running on your pc and that need to be install by each developer/client, or may be
    • Adhering to a light client server model: HTML frontend which submit queries to a server.

    Provide

    Tracability

    When was the bug open, and closed, what is its status now. Who has reported it (login is required and all system support profile (user, tester, manager, developer, administrator) and/or isolation of project). Did It already existed in a previous version (regression in code), etc...

    Responsability

     Easily dispatch responsability or find quickly who was reponsible for solving it, how  much time was needed to close this bug, some system may send email automatically to developer to inform them... etc...

    Effort

    How difficult will it be to solve this issues, (can be a bugnote add by other developer). Most of the time, technical leader decide of the value of this field together with developers.

    Priorities

    How many bugs are still open at a date "t", how do I determine the order in which I will solve them...etc

    Standardisation of records

    By forcing tester/customer to enter some mandatory fields in a graphical forms. It may avoid You to hear some ridiculous statement like: "the application is not printing, working". It force the user talking a language You have decide together, having agreed on a "bug category" list is a very good and common example.

    Customization

    All modern bug tracking tool let You define and customize some part of the system according to your need.

    Addition of information

    A screenshot is better than thousand word, a file create by the application, a memory dump, anything that will help developer to reproduce the bug.

    Statistics/Reporting

    A lot of very powerful queries can be executed. It is always interesting to know, how many improvement were done in the next/past releases, or if a team has use more power to develop new functionnalities (also changes request which interest the customer the most) or loose time tracking some low level bug priority.
    In case of reporting, Bugzilla support the following:
    • Tabular reports - tables of bug counts in 1, 2 or 3 dimensions, as HTML or CSV.
    • Graphical reports - line graphs, bar and pie charts.

    Al of the above will have a positive result on:
    • communication among the team of developers and customers,
    • It will improve the product quality by several magnitude,
    • Developer will be more productive as the will know what to concentrate on or what is worth to do.
    AND Your customers will be happier!!

    Golden rules

    1. A bug that can be reproduce can be analysed/corrected.
    2. Correcting a bug is not always trivial, a correction may introduce new bugs.
    3. The intrinseque quality of a software is always improved with a tracking tool over time

    Some open source software:


    Bugzilla (http://www.bugzilla.org/) is the more famous, use in a lot of open source application (Mozilla, Apache, and even eclipse) version 2.19.2 (MySQL+PHP, Solaris, Linux, Win32, MacOS X, BSD) 370 companies are currently using it. (Nasa, IBM, Mozilla and others)- Wikipedia has a very brief article on it, Features are listed here

    Mantis. (http://mantisbt.sourceforge.net/) A very simple bug tracking tool with limited search functionnality compared to bugzilla, a strong community but not so much stable release as expected.

    Buggit (http://www.matpie.drw.net/PBSystems/products/buggit/Buggit.html) no new release since 2000 and bounded to MS access, aka running only unde windows. Listed Here because I use to play with it in 2001.