Author: Miq

We developed an applet some years ago that was supposed to run 24/7. Basically, it fetches some values periodically and plots them in a chart. It always shows the last 24 hours. Everything seemed to work fine but every few weeks it crashed. The problems were clouded by hardware instabilities and the use of some obscure JVM. After quite a bit of analysis it became clear that it was a bug in our applet: a memory leak. Here is the troublemaker code:

for (int i = 0; i < dataSeries.getItemCount(); i++) {
    XYDataItem dataItem = dataSeries.getDataItem(i);
    if (dataItem.getX().longValue() < startDate.getTime().getTime()) {
        dataSeries.remove(i);
    } else {
        break;
    }
}
dataSeries.add(newDataPoint);

This simple and innocently looking piece of code essentially removes old items from a list by index. Many of you may already have spotted the main problem leading to the leak. Removing items by index means that following items shift one place towards the head of the list. As the index is incremented one element is skipped by the next iteration. This added up over time and lead to an OutOfMemoryError after some weeks.

Now, even if the code is not great it does relatively look straightforward on first sight, yet it is not and is contains errors. Making things worse, the code was buried somewhere in some tangled logic. This leads me to the point of my post:

Write unit tests even for relatively simple code.

Most likely writing a unit test for this cleanup work would have led to a class that manages the dataSeries and nothing more. Quite easy to understand and test in isolation. The problem would never have slipped into production and caused months of  investigating different stability problems.

The programmer may not have been aware of iterators but he should have made sure that this block works as intended. The best way to do this is automated unit tests. They make sure that your building blocks are as solid as you expect them to be. Use acceptance testing to make sure you have put your building blocks together the right way. Together unit and acceptance tests will save countless hours hunting regressions.

Having extensive acceptance tests is the basis of delivering high quality releases with very few regressions for long time projects. This is even more true when your environment uses dynamically typed languages and changing requirements. One of our Grails projects is running for several years now and continues to evolve and grow.  We are in dire need of more acceptance tests and especially their automated execution. Manual testing is not feasible and our coverage through unit and integration tests is not enough. We have a nice set of Selenium IDE acceptance tests already though. They were executed very infrequently which let some bugs slip through into production.

I want to describe our approach to automated and extensive acceptance testing below:

1. We create the acceptance tests using capture & replay with selenium IDE. This is a fast way to exercise a new feature through a repeatable test.
2. We think that maintaining the tests in code offers much more flexiblity and is easier to run in continuous integration (CI) than maintaining the selenium IDE html code. So we export the captured test to play nicely with the grails selenium-rc plugin. Kurt Harriger explains the setup and usage of the selenium-rc grails plugin. You need to make some changes to the exported code for everything to work nicely:
   1. Delete or change package declaration.
   2. Choose a grails functional test compatible file name like MyAcceptanceTests.groovy. We use the Junit4 export but Groovy export works also because the difference is only marginal and both must be adjusted in some places.
   3. Change the class name to match the file name without extension if they are not equal already.
   4. Change the exported test to extends from GroovyTestCase instead of *SeleneseTestCase.
   5. Add the @Mixin(SeleniumAware) annotation to the test class.
   6. Remove the setup and teardown methods.
   7. Replace verifyTrue() and friends with junit assertions.
3. Each test has to setup it’s initial state. This leads to independent acceptance tests at the expense of some longer running time but is well worth the cost imho.
4. The resulting selenium-rc tests can be run easily using grails test-app -functional and thus integration in the build process is pretty straighforward. We currently use ant to wrap the grails calls, but other ways may be more feasible depending on your infrastructure.

The end result is fast creation of acceptance tests and much flexibility setting up the test fixture and maintaining the tests. Using the grails plugin you gain easy execution of the tests on the developer machines and CI servers as well. With extensive automated acceptance tests the danger of regressions is greatly reduced. But be sure to not neglect unit and integration tests!

We have an ongoing long-term web application running on Grails. It started with Grails 1.0.3 and Grails moved on to 1.3.3 in the meantime. Due to time constraints and lack of resources we were not able to update to each new major version. Now, some years later, the time has finally come for us to benefit from all the new features, bugfixes and improvements of the platform. There were quite some changes in behaviour and one of the biggest is the change of how enums are mapped to the database.

In Grails 1.0.x and 1.1.x Java enums were mapped as int values in the database. Starting with Grails 1.2 they are mapped as varchars containing the enum name. Now you have the problem to migrate your existing data over to the new mapping style of the framework. One solution is to use autobase or liquibase migrations to port the enum values for the new mapping style.
Suppose we have the enum Coolness:

pulic enum Coolness {
    COOL, UNCOOL;
}

The SQL for migrating it on the PostgreSQL DBMS looks as simple like this:

alter table foo alter column bar type varchar
    using case when bar = 0 then 'COOL'
            when bar = 1 then 'UNCOOL'
            end

and as an autobase migration it becomes something like this:

changeSet(id: 'change foo bar from int to varchar', author: 'me') {
    preConditions(onFail: "CONTINUE") {
        dbms(type: "postgresql")
    }
    sql("""alter table foo alter column bar type varchar
            using case when bar = 0 then 'COOL'
                    when bar = 1 then 'UNCOOL'
                    end""")
}

We use the precondition to skip our non-persistent in-memory databases we use in development and only apply the change set with persistent test or production databases.

For Oracle and maybe other database systems which do not support altering the column type with the using-clause it may look like

alter table foo add bar_new varchar(255);
update foo set bar_new =
    (case when type = 0 then 'COOL'
            when type = 1 then 'UNCOOL'
      end);
alter table foo drop column bar;
alter table foo rename column bar_new to bar;

I hope this helps when you have to perfom similar migrations some time.

Stay tuned for other changes in API and behaviour between the different Grails framework versions.