Category Archives: JavaRanch

junit suite wide setup (not @BeforeClass)

Posted on by
1

Problem

How do I run setup/teardown for my whole suite, not just one class/test?

Impact of Problem

JUnit offers @Before to run a method before each test and @BeforeClass to run a method once before a class.  For a small suite, @BeforeClass may be enough.  For a large integration test suite, setting up the database is a common task that should be done once for scores of tests.  Having everything in one class is not optimal.  Nor is manually listing all the tests.

Requirements

  1. Continue being able to use ClasspathSuite to gather tests in a subdirectory at runtime.
  2. Run a method before the first of these tests is run
  3. Run a method after the last of these tests is run
  4. Take advantage of JUnit’s runner for running all the tests

Solution

package com.javaranch.test.functional;

import static org.junit.extensions.cpsuite.SuiteType.*;

import org.junit.extensions.cpsuite.*;
import org.junit.extensions.cpsuite.ClasspathSuite.*;
import org.junit.runner.*;

// use cpsuite to dynamically list out tests
@RunWith(ClasspathSuite.class)
@ClassnameFilters( { "com.javaranch.*test.*Test", "net.jforum.*test.*Test" })
// include in case have a parameterized test case
@SuiteTypes( { RUN_WITH_CLASSES, TEST_CLASSES, JUNIT38_TEST_CLASSES })
public class All_JForum_Functional_Tests {
public static void main(String[] args) throws Exception {
setUp();
JUnitCore.main("com.javaranch.test.functional.All_JForum_Functional_Tests");
tearDown();
}

private static void setUp() {
// create the database
}

private static void tearDown() {
// destroy the database
}
}

If you’ve been reading my blog, you’ll know I am doing this to integration test the back end of JavaRanch’s JForum install.  I started by cloning a database and have now moved on to the integration test framework.  Next I will describe the actual database setup.

clone a postgresql database for testing cleanly

Posted on by
4

I’m looking at writing integration tests for the back end of JavaRanch‘s JForum install.

A few “pesky” requirements/constraints

  • Multiple developers all over the word have their own local test databases filled with data in different states.  The tests must work for everyone.  Ideally they won’t leave data floating around either.
  • The tests must use PostgreSQL.  While the original JForum supported multiple databases, the JavaRanch version has been scaled down to just run with the one we need.  We do have some PostgreSQL specific SQL which rules out using an embedded database like HSQLDB or Derby.
  • Developers are using both Eclipse and IntelliJ.  Tests should care about the IDE anyway, so this isn’t a big constraint.
  • Developers are using a variety of operating systems and languages on their operating systems.  While code is in English, there can’t be assumptions as to the OS state.

Strategy

I think the best strategy is to create a second database just for testing.  The JForum database would remain untouched and a jforum_integration_test database can be created for the tests.  dbUnit can control the state of that special database.

The problem

Before I even start thinking about dbUnit, I did a proof of concept to ensure I could create a new database from scratch using the command line.  Creating a database is the easy part.  The “hard” part is that JForum doesn’t come with a schema.  It comes with an installation servlet that creates the schema.  While few people will be creating a schema for JForum, the technique I used applies elsewhere.

The procedure “before”

  1. Start up the JForum war
  2. Go to the JForum install URL and enter some information which creates the tables
  3. Run the JavaRanch customizations.

How to clone a database for which you only have a partial script

  1. Create an empty database
    createdb jforum_integration_test
  2. Arrive at the base schema
    1. Go the JForum installation URL
    2. Enter the information to create the tables
  3. Export the schema thus far
    pg_dump -U postgres jforum_integration_test > c:\temp\postgres.sql
  4. Provide instructions for the rest of the sql which were created by our developers.

How to import

Now for the easy part!

Importing this dump is a matter of a single command:

psql -U postgres jforum < "pathToWorkspace\JForum\javaranch-docs\deployment\file.ddl"

Lessons learned after

The next day I learned that this wasn’t enough.  We also needed some test data from the server.  I ran this a few times to get the relevant test data.

pg_dump --data-only --inserts -U user -W database --file roles  --table tableName

Conclusion

My next step will be to actually configure dbUnit against this new database and start writing tests.

javaranch forums go mobile

Posted on by
Reply

Want to know what went  on behind the scenes of JavaRanch’s mobile site creation?

Timeline

  • January 2009 – We started talking about how poorly the site renders on a BlackBerry
  • July 2009 – I got a BlackBerry for work.  And ugh.  The forums do look horrible.
  • August 2009 – Tried out BlackBerry emulator and explored the minimalistic approach possible to creating a mobile version (see next section.)  That didn’t work and I wasn’t prepared to spend a lot of time on it in the summer.
  • mid November 2009 – Start discussing design/UI.  Noted it took 4 minutes to edit a post via BlackBerry.  Very excessive.
  • late November 2009 – Restart development using approach #2.
  • December 2009 – Weekly deployments to production using “secret URL that only the moderators know” for beta testing.
  • January 3, 2010 – Mobile URL announced to public and added to e-mail notifications

Approach #1 – Mobile CSS

My original theory was that the easiest thing to do would be to just add a mobile stylesheet that would hide some columns.  It wouldn’t shrink the pages of course.  But as a first step: slow and readable beats slow and un-readable.  I quickly ran into some problems:

  1. The BlackBerry doesn’t like mobile stylesheets.  Bushido covers the options in a lot of detail.  Search for “Alright, alright. Gimme the code already!” for the ugly CSS imports.  The real problem is that you don’t have a mobile stylesheet with this technique.  You have a stylesheet that everyone uses called mobile and the main stylesheet which cancels out the main one.  Developing for this is crazy as you are compromising what stylesheets appear to do.  And it will break when RIM finally gets their act together.
  2. JForum uses a largely table based layout.  This doesn’t go well with CSS for hiding things.
  3. The table layout made changing anything incrementally very difficult.

Approach #2 – An actual mobile site

This approach is definitely more mobile friendly as the pages are designed to be mobile sized.  They are also written from scratch and get to use <div>s.  Basically what I did was take the real page, pick the most important parts and create div layouts for them.  Once I had one done, the rest followed easily.  There are a few limitations documented in the JavaRanch announcement site.  But overall, I’m happy with it.  It is certainly way better than what we had before.  And we will continue to tweak it.

Testing

I tested locally using the BlackBerry simulator and later with the Droid emulator. I also tested using my real BlackBerry after deploying to the test server.  The aggravation of using a real mobile device isn’t captured on the emulators!  It is possible to use testiphone.com as an emulator.  It is not completely accurate though.  In particular, it didn’t show the viewport problem.

<meta name=”viewport” content=”width = 320″ />

We also tested on a variety of real devices.  Many moderators tested on their personal handhelds and we got a good variety that way.

I’d like to thank a few people in particular.  Thank you to everyone who let me test on their device, especially

  1. Gregg Bolinger – for instant feedback in testing the viewport fix at 11pm on both the iPhone and the Droid.  (And more testing than anyone else.)
  2. A few coworkers (at my real job) – for the wide variety of devices I got to put my hands on.  The simulators really aren’t the same.  Five minutes on the real handheld at lunch really helped.
  3. Chuck from the NYC Spin for offering his tiny touch screen device (the smallest I’ve tested on) without my even asking!

Marketing

You know how sometimes marketing picks a ship date and it overrides “doneness” ?  Well, I really wanted to announce this on January 3rd – the one year anniversary of us being on Java based software.  There are some things that I wish were more resolved like why Google Mobilizer is injecting itself in links. Overall, I think it is in good shape and ready for people to try out though.

—

What do you think of the new site?  Share in the JavaRanch announcement thread or as a comment here!