Prefer Excel spreadsheets with FIT/FitLibrary

Since the invention of  FIT, now called FitLibrary, in 2002 a couple of new acceptance test frameworks with improved features appeared on the scene like FitNesse or Concordion.

But FitLibrary still remains a serious candidate to me, because tests can be written with Microsoft Word or Excel. Domain experts of the customer are usually accustomed to Word or Excel. I don't think you can convince a domain expert with no IT background to write or comment test specifications in Wiki markup like in FitNesse. Besides, you'd have to set up and run a FitNesse server that can be accessed by your acceptance testers or customer. With FitLibrary test documents can easily be exchanged by e-mail, e.g.

FitLibrary supports two document formats for test specifications: HTML or Microsoft Excel.
If you consider to use FitLibrary for acceptance tests, you shouldn't write your tests with Microsoft Word and save them as HTML file, because there are at least two pitfalls:

1.  If the cell's content gets too long, Word will insert a newline character somewhere in the middle of the cell's content, which you won't see in Word or a Web browser, but will likely break your test. In some cases you can work around this in your fixture code and strip off newline characters from the expected value. I found this behaviour of arbitrarily inserted newline characters in SeaMonkey's HTML editor, too.
2. If the rows of a table aren't exactly the same width, Word will insert placeholder cells or sort of compensation rows, which aren't visible. This might produce red cells in FIT's test reports.

Sharing IntelliJ IDEA Project Files (directory based format) in Version Control

Even if your project uses a build system like Maven that IDEA can leverage to automatically synchronize its library settings, there are still more project settings worth sharing with your project's version control system:

• Run configurations
• Code style settings
• Inspection profiles
• Version control settings
• File encoding settings
• Ant build configuration (if your project uses Ant)

First of all, the project module configuration files (.iml files) should be put under version control. With the new directory based project file format, the file modules.xml in the subdirectory .idea in your project's root directory should also be added to the VCS. Since module configuration files reference Java SDKs configured in IDEA your team should agree on a common naming of  them in IDEA or use the solution described in Hamlet D'Arcy article Sharing IntelliJ IDEA Project Files in Version Control on DZone. If your project doesn't depend on a specific update version of a JDK, naming SDKs in IDEA according to their major version ("1.6" for Java 6 SDK, e.g.) should do a good job and relieves your team members from installing JDKs and adjusting IDEA's SDKs concertedly.

Did you ever had to support a team member, because the application showed strange behaviour when run in his IDE and it turned out that he forgot to set one of the undocumented runtime parameters needed in the IDE runtime? Create a Shared Runtime configuration (Checkbox "Share configuration" in the Run/Debug Configurations dialog) and put it under version control. IDEA creates a file for each Shared Runtime configuration in the directory .idea/runConfigurations/.

If code quality is taken seriously in your project, configure the Code Style and the Inspection Profile and put the corresponding files .idea/projectCodeStyle.xml and the ones in .idea/inspectionProfiles/ under version control.

If your project uses Ant as build system and build scripts has been added to IDEA's Ant Build Tool, add the corresponding configuratin file ./idea/ant.xml to the VCS.

To share file encodings, VCS and IDEA compiler settings, add the files encodings.xml, vcs.xml and compiler.xml in .idea to the VCS. Finally, the file .idea/misc.xml should be added to the VCS.

Workspace-specific settings are kept in .idea/workspace.xml. Thus, this file should be ignored. As well as uiDesigner.xml if don't use IDEA's UI designer. IDEA creates these files after the project is opened the first time after checkout.

Things you can't share with version control:

Unfortunately, file templates available in the context menu New can't be shared, because they are saved in IDEA's configuration directory.

Pitfalls of migrating JUnit 3 test cases to JUnit 4

How to migrate JUnit 3 test cases to JUnit 4 is explained in Get Acquainted with the New Advanced Features of JUnit 4, e.g.
But after I migrated my tests as described, some of my tests didn't work, anymore. Tests extending  a common abstract base class that provided common setup and teardown logic:

abstract class AbstractTestCase extends TestCase {

   protected AbstractTestCase() {
   }

   @Before
   protected void setUp() throws Exception {
      // common setup logic
   }
}

Although I added the Before-Annotation to the setUp()-method, it didn't get called. So, I changed the visibility of the method to public. This didn't fix the problem, either. After some pondering and fruitless searches on the Web, I changed the visibility of AbstractTestCase from package-protected to public. Behold, it worked again.