One problem that you may have encountered when attempting to write a test for an abstract class is that, well, you can’t instantiate it.  So how do you test it?

I was wondering the same thing a few weeks ago.  I had the following abstract class (simplified for readability and understanding):

public abstract class MyAbstractClass {

 protected String getDefaultOrder() {
 return getDefaultFetch().split(",")[0];
 }

 protected abstract String getDefaultFetch();
}

I wanted to write a simple test that would verify that getDefaultOrder() would perform as expected and return the first word in the comma-delimited string returned by getDefaultFetch().

Luckily, I stumbled upon Mockito’s thenCallRealMethod() method. This made the test easy to write:

public void defaultOrderShouldBeFirstWordInDefaultFetch() {
 MyAbstractClass abstractClass = mock(MyAbstractClass.class);

 when(abstractClass.getDefaultFetch()).thenReturn(
 "Rank,FormattedID,Name,PlanEstimate,Priority,Owner,ClosedDate,CreationDate"
 );

 when(abstractClass.getDefaultOrder()).thenCallRealMethod();

 assertEquals(abstractClass.getDefaultOrder(), "Rank");
 }

As you can see, we’re telling Mockito that when the getDefaultOrder() method gets called on the mock object “abstractClass”, Mockito should execute the real getDefaultOrder() defined in our MyAbstractClass class. This is contrary to Mockito’s default behavior of simply returning the default value for the return type of the method called on the mock object (in this case, for getDefaultOrder()’s return type of String, Mockito would return null).

So there you go: an easy way to test methods in abstract classes!

When testing interactions with mocks, some common code patterns can be difficult to test.

We recently encountered a case in a controller where we were talking to a wrapper for a third party service. Our wrapper would new-up a data transfer object based on the parameters provided by the controller and pass that query object to the third party.

Controller code:

    public ModelAndView doSomethingUseful(
            @RequestParam("name") String name,
            @RequestParam("order") String order)
    {
        Iterable<MyModel> queryResult
                = serviceWrapper.queryByName(name, order);

        return new ModelAndView("myView", "myModels", queryResult);
    }

Service wrapper code:

    public Iterable<MyModel> queryByName(String name, String order) {
        ThirdPartyDTO dto = new ThirdPartyDTO();
        dto.setParameter("name", name);
        dto.setOrder(order);
        dto.setFilter("type", MyModel.class.getName());
        return service.query(dto);
    }

While the code in both classes is fairly concise and easy to read, it is difficult to verify that the correct query logic was applied to the DTO. Because the DTO is constructed in the method call on the wrapper and never returned, it’s hard to write a test for that method. We could construct the DTO in the controller and make the service easy to test, but that would have just moved the problem. We could have introduced a factory to return new instances of the DTO then mocked that to return mocks and verify that the correct methods were called, but mocks returning mocks is a code smell.

What we settled on was introducing an intermediate class:

public class DTOBuilder {
    private Class aClass;
    private String order;
    private String name;

    public DTOBuilder(Class aClass) {
        this.aClass = aClass;
    }

    public DTOBuilder withName(String name) {
        this.name = name;
        return this;
    }

    public DTOBuilder orderBy(String order) {
        this.order = order;
        return this;
    }

    public ThirdPartyDTO buildDTO() {
        ThirdPartyDTO dto = new ThirdPartyDTO();
        dto.setParameter("name", this.name);
        dto.setOrder(this.order);
        dto.setFilter("type", this.aClass.getName());
        return dto;
    }
}

Now we can write tests verifying that when buildDTO is called, the correct values are set on the resulting DTO. It’s a simple test to write, and it doesn’t involve any mocks. Additionally, our service wrapper code is simplified…

public class ServiceWrapper {
    private ThirdPartyService service;

    public ServiceWrapper(ThirdPartyService service) {
        this.service = service;
    }

    public Iterable<MyModel> query(DTOBuilder builder) {
        return service.query(builder.buildDTO());
    }
}

.. and we can now write a test for our service wrapper pretty easily:

    public void queryShouldPassDTOFromBuilderToThirdPartyService() {
        DTOBuilder builder = mock(DTOBuilder.class);
        ThirdPartyService service = mock(ThirdPartyService.class);

        ThirdPartyDTO dto = new ThirdPartyDTO();
        Iterable<MyModel> expected = new ArrayList<MyModel>();

        when(builder.buildDTO()).thenReturn(dto);
        when(service.query(dto)).thenReturn(expected);

        ServiceWrapper wrapper = new ServiceWrapper(service);
        Iterable<MyModel> actual = wrapper.query(builder);

        assertEquals(actual, expected);
    }

To this point however, we’ve actually made our controller harder to test. While the code from the controller is clean and reads very well, it’s no longer easy to test:

    public ModelAndView doSomethingUseful(
            @RequestParam("name") String name,
            @RequestParam("order") String order)
    {
        DTOBuilder DTOBuilder = new DTOBuilder(MyModel.class)
                .withName(name)
                .orderBy(order);

        Iterable<MyModel> queryResult = serviceWrapper.query(DTOBuilder);

        return new ModelAndView("myView", "myModels", queryResult);
    }

A nice feature of IntelliJ and an understanding of mockito can help us out here. The when method in mockito relies on object equality to determine whether an expectation has been met. By overriding equality in our builder class, we can write our controller test like this:

    public void doSomethingUsefulShouldBuildExpressionAndDelegateToService(){
        ServiceWrapper serviceWrapper = mock(ServiceWrapper.class);
        Iterable<MyModel> models = new ArrayList<MyModel>();

        DTOBuilder builder = new DTOBuilder(MyModel.class)
                .withName("foo")
                .orderBy("bar");

        when(serviceWrapper.query(builder)).thenReturn(models);

        HypotheticalController hypotheticalController = new HypotheticalController(serviceWrapper);
        ModelAndView result = hypotheticalController.doSomethingUseful("foo", "bar");

        assertEquals(result.getModel().get("myModels"), models);
    }

Notice that this test verifies that the correct logic was applied to the DTO without over-relying on mocking and without using verify. It reads well and clearly communicates the intent of the production code.

Where does IntelliJ come into the equation? Writing the equality logic for the builder would be tedious and error prone to do by hand. Luckily, IntelliJ knows how to do it for us. Pressing Command+N brings up the code generation window (that’s on the mac – check the IntelliJ documentation for the shortcut on your platform). Choosing “equals() and hashCode()” from the resulting menu gives us this:

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;

    DTOBuilder that = (DTOBuilder) o;

    if (aClass != null ? !aClass.equals(that.aClass) : that.aClass != null) return false;
    if (name != null ? !name.equals(that.name) : that.name != null) return false;
    if (order != null ? !order.equals(that.order) : that.order != null) return false;

    return true;
}

@Override
public int hashCode() {
    int result = aClass != null ? aClass.hashCode() : 0;
    result = 31 * result + (order != null ? order.hashCode() : 0);
    result = 31 * result + (name != null ? name.hashCode() : 0);
    return result;
}

At Rally, we’ve stayed committed for the last 7 years to never telling the business that the product has to halt active development to pay down technical debt. For us, the “big rewrite in the sky” has always been off the table. Instead, we prefer to incrementally refactor and improve the existing elements of the codebase, gradually getting it to where we want it to be without ever halting feature development completely.

This has never been an easy task. The truth is, the codebase is quite old by engineering standards, many parts of it written before standards emerged in the industry. Our entire persistence layer, for example, was created by hand well before libraries such as Hibernate existed (or at least, before they became standard practice). This means that there are many, many areas of the code that we’d like to attack and improve.

One thing we’ve started doing is holding lunchtime “refactotums,” where we take a look at some code and try to improve it. Of course, with such a large codebase, and so many areas of the code that have not been touched since they were first written, we’ve often wondered how to most effectively spend our refactotum time. This led us to wonder “what are the areas of the code where a refactoring would have the greatest impact?”

We started keeping track of our codebase using Sonar which was extremely helpful in keeping track of metrics at a class level, but it didn’t give us quite enough information. For example, if Class A has a complexity score of 500 and Class B has a complexity score of 200 (higher is worse), you’d think that spending some time cleaning up Class A would be the most effective thing to do. But what if Class B is used by 50 times as many other classes as Class A? Or what if Class B, complicated as it is, has never been modified in the history of the project? It would be nice to clean this class up, but it might be a better use of time to focus on Class A

So our idea was to combine two metrics: the class complexity (based on McCabe Cyclomatic Complexity) and the number of times a file has been modified in the codebase. The idea here was, every time a file has to be modified, it has to be read. A complex file is harder to read, making the engineer more likely to misunderstand or make a mistake while editing the file.

Luckily, git makes it quite easy to count the number of modifications to files in the codebase:

git whatchanged | grep '^:.*alm-webapp/src/main/java/.*\.java$' | cut -c65- | sed -e 's/\//./g' -e 's/.java//' | sort | uniq -c | sort -r

Obviously, the grep and cut would have to be modified slightly depending on your codebase structure. The grep is used to ensure only our code is looked at, excluding any third-party code in the system. The cut and seds are mostly just about munging the filenames into “probable” classnames, since that’s more useful (and what Sonar stores).

This command yields some high-traffic files, but it needs to be combined with high-value targets as well. For this, we turned to Sonar.

We were unable to use the Sonar web services as thoroughly as we were hoping, so we wound up writing a query directly against the database where the Sonar data is stored. The query for a given metric (in our case, metric 12, class complexity) looks like this:

    SELECT projects.kee, project_measures.value, project_measures.metric_id
    FROM snapshots, project_measures, projects
    WHERE islast = 1
      AND project_measures.snapshot_id = snapshots.id
      AND project_measures.metric_id = 12
      AND snapshots.qualifier = 'CLA'
      AND snapshots.project_id = projects.id

We wrote a Ruby script that pulled the data from these two sources and correlated them together, deriving an eventual “weighted rank” from the two. We went on to include a few more metrics in the final equation. Output from the script looks like this:

Calculating complexity data from sonar...Done!
Calculating revision data from git...Done!
Calculating weighted rank data...Done!
Current formula:
   ( 0.15 * ( complexity / average_complexity ) )
 + ( 0.40 * ( function_complexity / average_function_complexity ) )
 + ( 0.30 * ( efferent_coupling / average_efferent_coupling ) )
 + ( 0.40 * ( revisions / average_revisions ) )

Rank    Score  Revisions  Complexity  F.Complexity  E.Coupling  Class
----  -------  ---------  ----------  ------------  ----------  -----
   1    14.12         60         507             2          67  com.rallydev.ClassG
   2    13.10         93         301             2          71  com.rallydev.ClassQ
   3    12.53         80         318             2          70  com.rallydev.ClassR
   4    11.25         11          45            45          27  com.rallydev.ClassO
   5     9.65          9          43            43           8  com.rallydev.ClassC
   6     9.48         72         194             2          52  com.rallydev.ClassZ
   7     9.24         60         205             2          56  com.rallydev.ClassN
   8     8.79         42         218             2          59  com.rallydev.ClassK
   9     8.75         31         260             3          53  com.rallydev.ClassF
  10     8.63         54         167             2          59  com.rallydev.ClassT
  11     8.38         65         194             2          39  com.rallydev.ClassO
  12     8.29         44         207             3          49  com.rallydev.ClassY
  13     7.81         40         225             2          41  com.rallydev.ClassP
  14     7.48         18          26            26          23  com.rallydev.ClassK
  15     7.44         60         164             2          34  com.rallydev.ClassA

We’ve found it pretty useful to know where our efforts would be most useful. If you’re using git and sonar, feel free to modify this script and try it on your own codebase (note, you will need the mysql client binary in your path for it to work).

#!/usr/bin/env ruby
# Authors: Rod Hilton and Ryan Scott
# Site: www.rallydev.com

METRICS = {12=>:complexity, 14=>:function_complexity, 74=>:efferent_coupling}
WEIGHTS = {:revisions=>0.4, :complexity=>0.15, :function_complexity=>0.4, :efferent_coupling=>0.3}

def print_around(title, &block)
  print title + "..."
  STDOUT.flush
  yield block
  print "Done!\n"
end

def add_class_data(class_data, class_name, data_key, data_value)
  class_data[class_name] = {} unless class_data.has_key?(class_name)
  class_data[class_name][data_key] = data_value
end

def add_complexity_data(class_data)
  complexity_query = <<-EOF
    SELECT projects.kee, project_measures.value, project_measures.metric_id
    FROM snapshots, project_measures, projects
    WHERE islast = 1
      AND project_measures.snapshot_id = snapshots.id
      AND project_measures.metric_id in (#{METRICS.keys.join(",")})
      AND snapshots.qualifier = 'CLA'
      AND snapshots.project_id = projects.id
    EOF

  print_around "Calculating complexity data from sonar" do
    complexity = `echo "#{complexity_query}" | mysql -h alm-build --user=YOUR_SONAR_USERNAME --password=YOUR_SONAR_PASSWORD --database=YOUR_SONAR_DATABASE`

    complexity.each do |complexity_line|
      match = complexity_line.match(/^(\S*)\s+([\d\.]+)\s+(\d+)$/)
      if(match)
        name = match[1]
        metric = match[2].to_f
        metric_id = match[3].to_i
        metric_name = METRICS[metric_id]
        add_class_data(class_data, name.match(/^.*:([^:]*)$/)[1], metric_name, metric)
      end
    end
  end
end

def add_revision_data(class_data)
  print_around "Calculating revision data from git" do
    file_changes = `git whatchanged | grep '^:.*alm-webapp/src/main/java/.*\.java$' | cut -c65- | sed -e 's/\\//./g' -e 's/.java//' | sort | uniq -c | sort -r`
    # file_changes = `cat modified.txt`

    file_changes.each do |file_change_line|
      match = file_change_line.match(/^\s*(\d+)\s+(.*)$/)
      if(match)
        revisions = match[1].to_i
        name = match[2]
        add_class_data(class_data, name, :revisions, revisions)
      end
    end
  end
end

def average_for_data(class_data, key)
  values = class_data.values.collect{|val| val[key]}
  values.inject{ |sum, el| sum + el }.to_f / values.size
end

def add_weighted_rank_data(class_data)

  print_around "Calculating weighted rank data" do
    averages = {}
    WEIGHTS.each do |key, value|
      average = average_for_data(class_data, key)
      averages[key] = average
    end

    class_data.each do |classname, data|
      data[:weighted_rank] = 0
      WEIGHTS.each do |key, weight|
        chunk = weight * (data[key] / averages[key])
        data[:weighted_rank] = data[:weighted_rank] + chunk
      end
    end
  end
end

def remove_classes_without_all_data(class_data)
  num_keys = class_data.values.map{|val| val.size}.max
  class_data.delete_if{|key, val| val.size < num_keys}
end

# --- Main ---

class_data = {}

add_complexity_data(class_data)
add_revision_data(class_data)

class_data = remove_classes_without_all_data(class_data)

add_weighted_rank_data(class_data)

#Sort by rank, descending
class_data_sorted = class_data.sort{|a,b| b[1][:weighted_rank] <=> a[1][:weighted_rank]}

puts "Current formula: "
pieces = []
WEIGHTS.each do |key, weight|
  pieces << sprintf( "( %3.2f * ( %s / %s ) )", weight, key.to_s, "average_"+key.to_s)
end
puts "   " + pieces.join("\n + ")

puts "\n"
puts "Rank    Score  Revisions  Complexity  F.Complexity  E.Coupling  Class"
puts "----  -------  ---------  ----------  ------------  ----------  -----"
class_data_sorted[0..49].each_with_index do |file, index|
  class_name=file[0]
  class_data=file[1]
  printf("%4u  %7.2f  %9u  %10u  %12u  %10u  %s\n", (index+1), class_data[:weighted_rank], class_data[:revisions], class_data[:complexity], class_data[:function_complexity], class_data[:efferent_coupling], class_name)
end

Feel free to make any improvements or changes to this script that you wish. It’s not the most efficient in the world, but it was thrown together pretty quickly to get a decent idea of our highest-impact refactoring targets.

Suggestions for improving the formula? Made your own changes to the script? Feel free to post in the comments below, we welcome the discussion!

We have recently started to write our browser based tests with Selenium 2.0. and the WebDriver api. We like the direct control over the browser versus the JavaScript execution of Selenium 1.0.

I also stumbled across Sauce Labs and its Sauce OnDemand product. I really would like to not maintain a huge grid of different browsers and operating systems, having them available “in the cloud” seems like a much better option. It also aligns better with the companies efforts to be more green. Unfortunately, Sauce OnDemand is a Selenium 1.0 version of Selenium Remote Control. Bummer. I took some time and at got a very basic example working using WebDriver and Sauce OnDemand.

Here is a simple TestNG test that verifies the title of google.

package com.rallydev.acceptance;

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.remote.CommandExecutor;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;

import java.net.URL;

import static org.testng.Assert.assertEquals;

@Test
public class SauceLabsTest {

    private WebDriver driver;

    @BeforeMethod
    protected void setUp() throws Exception {

        String browserString = new SauceLabsBrowser("sauceusername", "sauce-api-key-goes-here", "Windows 2003", "firefox", "3.", "WebDriver example").toJson();

        DesiredCapabilities capabilities = new DesiredCapabilities();
        capabilities.setBrowserName(browserString);
        CommandExecutor executor = new RallySeleneseCommandExecutor(new URL("http://saucelabs.com:4444/"), new URL("http://www.google.com/"), capabilities);
        driver = new RemoteWebDriver(executor, capabilities);

    }

    @AfterMethod
    protected void tearDown() throws Exception {
        driver.quit();

    }

    public void sauceLabsWorks() throws Exception {
        driver.get("http://www.google.com/");
        assertEquals("Google", driver.getTitle());
    }
}

I had to extend the SeleneseCommandExecutor so the JSON browser name that Sauce wants doesn’t blow up. Here is the code for the what I called the RallySeleneseCommandExecutor:

package com.rallydev.acceptance;

import com.thoughtworks.selenium.HttpCommandProcessor;
import org.openqa.selenium.SeleneseCommandExecutor;
import org.openqa.selenium.remote.Capabilities;

import java.net.URL;

public class RallySeleneseCommandExecutor extends SeleneseCommandExecutor {
    public RallySeleneseCommandExecutor(URL seleniumServer, URL remoteAddress, Capabilities capabilities) {
        super(
                new HttpCommandProcessor(
                        seleniumServer.getHost(),
                        seleniumServer.getPort(),
                        capabilities.getBrowserName(),
                        remoteAddress.toString()
                )
        );
    }
}

The only other thing I did to make life easier was to create the SauceLabsBrowser class. All it does it put all the arguments into map and then convert the map to JSON. I can only handle string concatenation for so long

package com.rallydev.acceptance;

import net.sf.json.JSONObject;

import java.util.HashMap;
import java.util.Map;

public class SauceLabsBrowser {

    private Map<String, String> sauceParams;

    public SauceLabsBrowser(String username, String accessKey, String os, String browser, String browserVersion, String jobName) {
        this.sauceParams = new HashMap<String, String>();

        this.sauceParams.put("username", username);
        this.sauceParams.put("access-key", accessKey);
        this.sauceParams.put("os", os);
        this.sauceParams.put("browser", browser);
        this.sauceParams.put("browser-version", browserVersion);
        this.sauceParams.put("job-name", jobName);
    }

    public String toJson() {
        JSONObject jsonObject = new net.sf.json.JSONObject();
        jsonObject.putAll(sauceParams);
        return jsonObject.toString();
    }
}

There is still a decent amount of work to do. I found there a bunch of WebDriver commands that aren’t yet implemented in the SeleneseCommandExecutor. I hope to fix that and get a patch send to the Selenium people soon. Hope this at least gets people started.

Ben Whaley of AppliedTrust and I recently spent a few months putting together a security model for Rally. We analyzed each module of our Java-based stack, detailing and capturing security considerations along the way. We relied on OWASP as a standardized framework for guiding our process. The goal of the project was to conveniently describe the Rally approach to security at the application layer. Additionally, this model has proven essential for newer members of our development team.

Many companies, particularly SaaS companies, can benefit by having a published security model. Since we had never seen anything quite like this, and because we believe in the open exchange of information, we decided to share the model with the public. Ben and I presented a talk entitled “Effectively marketing security as a win for both the business and the customer” at Front Range OWASP Conference 2010 where we presented the model detailing Rally’s approach to securing our SaaS product. Feel free to take a look at our slides.

We can now arm our sales team with a straightforward (even pretty) picture that represents exactly how we handle security throughout the application. This should assist us with answering questions in those difficult RFP documents from our more security-conscious customers. Also, I truly believe that having our security approach out there for the whole world to see shows a certain level of confidence. It’s clear that we’re not just doing a “security by obscurity” approach.

The development team at Rally has been growing during the last year and it can be difficult to train developers, especially from a security standpoint. The security model serves dual purpose from a training perspective. We now have a current architecture diagram that visually depicts security at each layer of the stack.

Our hope is that other companies can use this model as an example. There was no existing reference point when we started this project, so we chose to share ours.  The software development industry generally, and next-generation web platforms specifically, can only benefit from being more security-aware as increasingly sensitive data is made available via the web.

Recently we’ve been expanding our suite of “Smoke Tests”.  Smoke Tests is our term for the GUI tests that we’ve written for the purpose of testing common, happy-path actions in the Rally application.  These tests are written in Java using the Selenium API.

During the process of writing these tests, we’ve ran into a few situations where we needed to do seemingly simple actions through the web browser, but we weren’t able to immediately come up with solutions simply by looking at the Selenium API.  I’d like to highlight a few of these below:

1.  Interacting with WebElements in iframes
In one of our Smoke Tests for an editor in the Rally Application, we wanted to enter some text into the the “Description” field in the editor.

The Description field uses our rich-text editor, and the text box where the Description text can be entered is enclosed inside of an iframe.  The setValue method below shows the code we were trying to use to enter text into this field:

public class RichTextField
{
private String iframeId;
private WebDriver webDriver;

public RichTextField(String iframeId, WebDriver webDriver)
{
this.iframeId = iframeId;
this.webDriver = webDriver;
}

public void setValue(String value)
{
webDriver.findElement(By.cssSelector("#" + iframeId + " body")).sendKeys(value);
}
}

When we tried to access the body element of the iframe with the call to By.cssSelector(…), Selenium was unable to find the body element.  This is because it was inside of the iframe.

Fortunately, after some searching we were able to find the switchTo() method on WebDriver.  This did the trick:

public class RichTextField
{
private String iframeId;
private WebDriver webDriver;

public RichTextField(String iframeId, WebDriver webDriver)
{
this.iframeId = iframeId;
this.webDriver = webDriver;
}

public void setValue(String value)
{
webDriver.switchTo().frame(iframeId).findElement(By.tagName("body")).sendKeys(value);
webDriver.switchTo().defaultContent();
}
}

Notice the webDriver.switchTo().defaultContent() line.  This is necessary so that the WebDriver instance’s context is switched back to the main page instead of being inside of the iframe, which is the result of the first statement in setValue.

2.  Selecting a Value From an Ext.form.ComboBox
In another one of our Smoke Tests, we wanted to click the “Create New User” option from our new auto-suggest text box on the Project-Users grid.  This auto-suggest box is built using ExtJS’ Ext.form.ComboBox object.

Text needs to be entered into the auto-suggest textbox so that the drop-down box containing the “Create New User” option will render.  We thought this could be accomplished using the following code in the sendKeys method (comboTextBox is the WebElement corresponding to the auto-suggest textbox):

public class Combo
{
private WebElement comboTextBox;

public Combo(WebElement comboTextBox)
{
this.comboTextBox = comboTextBox;
}

public void sendKeys(CharSequence text)
{
comboTextBox.sendKeys(text);
}
}

However, we noticed that unless the Firefox window that was running the test was the focused window, the drop-down box (with the link we wanted to click) would never appear regardless of what was typed into the auto-suggest text box.  Wierd, huh?

After much head-shaking, we looked at the expand method in Ext.form.ComboBox:

expand : function(){
if(this.isExpanded() || !this.hasFocus){
return;
}
this.list.alignTo(this.wrap, this.listAlign);
this.list.show();
this.innerList.setOverflow('auto'); // necessary for FF 2.0/Mac
Ext.getDoc().on('mousewheel', this.collapseIf, this);
Ext.getDoc().on('mousedown', this.collapseIf, this);
this.fireEvent('expand', this);
}

We put some alerts in the there, and noticed that hasFocus was false!  This meant that expand() did nothing, and that’s why our auto-suggest box was never expanding!  hasFocus is set to true in the onFocus() method of ComboBox, which is called when the focus event is fired (hence the name ).  So we modified our sendKeys method to attempt to explicitly focus the ComboBox by clicking on it:

public void sendKeys(CharSequence text)
{
comboTextBox.click();
comboTextBox.sendKeys(text);
}

Still no luck!  hasFocus was still false.  After some searching, we stumbled on this article.  This led us to believe that the focus event was never being fired in our Firefox browser.  So we got creative:

public class Combo
{
private WebElement comboTextBox;
private WebDriver webDriver;

public Combo(WebElement comboTextBox, WebDriver webDriver)
{
this.comboTextBox = comboTextBox;
this.webDriver = webDriver;
}

public void sendKeys(CharSequence text)
{
((JavascriptExecutor) webDriver).executeScript("Ext.getCmp('project-user-auto-suggest').onFocus()");
comboTextBox.sendKeys(text);
}
}

This is really awesome because we were able to use the Ext.getCmp method from the ExtJS framework that we use in our application to get our auto-suggest ComboBox (”project-user-auto-suggest” is the id of the component), and then we could make up for the browser’s inability to fire the focus event by simply calling onFocus() ourselves.  This worked like a charm.  So awesome!

The other day I needed to cache some data that should expire. Thanks to Google Collections this was incredibly easy.

The entries in this map will expire in 1 hour. Super easy and pretty clean too. Thanks Google.

ConcurrentMap<String, String> cache = new MapMaker().expiration(1, TimeUnit.HOURS).makeMap();

Rob Park and I will be hosting a CodeRetreat at Rally on March 27th.

What is a CodeRetreat (taken from the CodeRetreat Ning site)?

At CodeRetreat, we retreat from the world to advance in our craft. We sharpen our saws, together. We retreat from production and business value to increase our production capacity, our quality, our velocity, our ability to produce business value. We retreat from immersion in deep technology weeds (Oh no! The JBoss ClassLoader is giving me CCE’s!) to advance in our ability to learn and adopt to any technology well. We retreat from our fears, and embrace new practices, patterns, languages.

We retreat from our local ponds and swim in a larger pool. We connect with other passionate coders who we seldom get to code with. We make new connections and learn new lessons.

Code Retreat Format

• Problem: Conway’s Game of Life
• Length of Iterations/Sessions: 45 minutes
• Duration: 8am to 5pm
• Language: Java

This will be a fun day for all. Breakfast and Lunch will be provided. If you will be attending, please register at http://coderetreat.ning.com/ or send me an email at aesterline at rallydev dot com.

In our quest for ever-faster build times, we noticed that a large portion of our time running tests was getting the next OID for persisted objects.

After some investigation, we discovered the bottleneck. For every persisted object created in the system, a new connection was obtained from our datasource and a query was issued to retrieve a single OID. I know, I know… not very efficient. We wanted to refactor the code to grab batches of OIDs and cache them in memory.

How do we get groups of OIDs from an Oracle sequence? We had a couple of choices.

Modify the sequence’s INCREMENT BY to something larger than one.
We liked this approach because it allowed us to get a batch of OIDs with one query. But.. This approach has problems for external code that inserts data into our database. The external code would also have to know about the change in INCREMENT BY.

Changing all of the external integration code seemed like a big task. We wanted to find an approach that allowed us to keep the sequence unchanged, but allowed us to get a batch of OIDs with one query.

Query the sequence for a batch of OIDs
How do we do that? We need a query in Oracle that will generate N number of results. We tried several queries before we finally settled on one clever query. (Or at least it was clever to us.)

SELECT SEQ.nextval FROM (SELECT LEVEL FROM DUAL CONNECT BY LEVEL <= :1)

The clever part is the CONNECT BY LEVEL. This allows us to generate an arbitrary number of rows in our result set. The sequencer does the rest. We capture the results from the query and hand them out in memory. This query gave us the best of both worlds. We got to get a batch of OIDs with one query without having to change any of our external systems.

Where do we go from here?
In a word, GUIDs. This was a necessary performance related step on the way to implementing GUIDs.

One of the most common sources of tension between product owners and developers is when product owners are surprised at how high an estimate for a story might be. Usually this tension is easy to resolve by reiterating that the product owners really have no concept of how much something should cost. However, there is one scenario I see over and over again: when a product owner protests the estimate of a story because it seems, to the PO, like it’s simply re-using an aspect of the system somewhere else.

“I already paid for that!” he or she might say, quite correctly. A simple example recently for us here was our column picker. Our grids allow you to select which columns you wish to see on any given grid. Later on, we created the ability to have grids inside of panels on user dashboards. Our product owner wanted to put the column picker on the settings pane of a grid panel. To him, this was simply reusing the column picker that had already been created for an earlier story. He was quite shocked when our estimate for the effort was just as high as it was the first time.

His frustration is completely understandable. How is this possible? Why isn’t it easy to just drop that component into another place and have it work? After all, if we were good engineers, wouldn’t we have written that component to be reusable?

Actually, no. It’s because we were good engineers that it wasn’t written in that way. This is one of the hardest things for product owners to understand, and I hope to explain it in this post.

Evolutionary Design

Once upon a time, development teams worked in specific phases. First they would design all of the code they were going to write; boxes would be drawn on whiteboards, sequences captured in documents, and so on. Once the design was finished, the developers would go off and write the code for it. Luckily, our industry has realized that this is a problematic way to write software.

It’s simply not likely that the team will discover all of the quirks of the design during the design phase. It’s even more likely that requirements and features will change during the long span of time this process takes, forcing the developers to throw away work and go “back to the drawing board” on the design. Splitting the design phase from the coding phase is a recipe for disaster.

Instead, it’s generally preferable to practice evolutionary design; allow the design to grow organically as the code is written. This, combined with testing and refactoring, seems to be the best known way to ensure that the quality of the code remains high as a product grows.

Doing this makes it easier to deal with changes that effect design, and it prevents the team from wasting time going “back to the drawing board” in the event a problem is discovered.

YAGNI

One principle to follow as you code is the YAGNI principle. YAGNI means “You Ain’t Gonna Need It” and essentially it means that developers should discourage themselves from adding additional code to support something that is not, at the time, required. Developers have a strong desire to add code here or there while editing code, and YAGNI helps us remember to resist the urge to add superfluous code or functionality.

Following this principle helps eliminate waste, and helps keep developers focused on adding value that product owners want. But why?

If I’m editing Module A to add Functionality X, why not just add Functionality Y while I’m there? It may delay the delivering of Functionality X in the short-term, but later when it’s decided that Functionality Y must be supported as well, it will be dirt cheap, right?

The trick to understanding why YAGNI helps is realizing that there are thousands upon thousands of potential Module As in a system. The truth is, Functionality Y may simply never be required. And even if it is, Functionality Z may not be. Adding that functionality would be a waste of time and resources if it’s never used.

YAGNI Applied to Design

The same principle behind YAGNI can be extended to aspects of high-level design. When we originally designed the Column Picker component, it was not designed to be dropped into any part of the system. This was intentional: if we had spent the time to make the Column Picker completely generic and reusable, but then had never needed to drop it into another part of the system, the additional effort required to make it super-generic would have been a wasted effort. This is true for any aspect of the system being designed: we can spend the extra time and effort to make something extremely generic, but if that generality is never needed, that time is waste. Many times developers will refer to something that’s overly generic as “over-engineered.”

This means that the description of the component can often be misleading. We never built “a column picker” – we built “a column picker for a grid page”. The column picker was written in a way that assumed it was part of a grid page. Again, it could have been written more generically, but doing so would have potentially created waste (this does not mean that it’s alright to design code that violates principles of good design. Code can be well-designed but still not fully generic).

So when it came time to put the component in a completely different context than the one for which it was designed, it was still a lot of work: almost as much as was originally required to make the first pass. Though some time was saved simply because it was a known and well-understood problem for which we would leverage newly-developed knowledge, it still effectively required writing a whole new component: one that was much more generic and utilized what it could of the previous increment.

Essentially, to avoid having developers waste time, components should be “generic on demand”. Once a component needs to be reused, then it should be refactored into something extremely generic, but not before. The end result is that a product owner will have to pay for a component twice before it’s cheap.

This may seem counterintuitive to product owners, but it’s important to understand. Because the team approaches coding in a way that causes the second time to be nearly as expensive as the first, the team is able to deliver everything else quickly.

The first time, it is costly because the developers have to solve unknowns and create something new from scratch.

The second time, it is costly because it has to be molded into something generic and reusable.

The third time, however, is cheap.