Running JUnit Tests Standalone
You can run the Pentaho JUnit tests without an application server. We use a standalone context and session to start the required engines in the server, and then each JUnit test exercises its individual feature or function, without the complications of an application server.
You will need to make a few configuration file changes in order for this to work. Follow the instructions given below. I have based these instructions on running JUnit tests through the Eclipse IDE, but there is no reason why they shouldn't work for other development environments just as well.
Requirements
In order to run the JUnit tests for the Pentaho BI Server, you will need to have at least three projects from our SVN repository: the pentaho project, the pentaho-data project and a pentaho-solutions project. You can find instructions on how to get Pentaho projects from SVN here.
You do not need Eclipse or a Java SDK to follow the setup instructions for running the JUnit tests, but in order to actually run them, you will need the Java SDK, and some sort of Java development environment. You can read about the Eclipse setup that the Pentaho team uses here.
Necessary Tweaks to the Server Configuration
In order to run the server standalone, there are a number of "tweaks" we need to perform to align things just right, and exclude those components (like security) that are not necessary during a JUnit test run.
1. Modify TestSettings.java
First we need to hardcode the location of our solution project in the TestSetttings.java file. If we were running the server in a web container, it is smart enough to recursively search the directory hierarchy to locate the "pentaho-solutions" directory (or alternately check the web.xml file). Standalone, we are not quite as clever.
You can find this file in [PentahoDoc:pentaho_project]/server/pentaho/test/org/pentaho/test/TestSettings.java.
...
Change the value of the DEFAULT_LIB_PATH field to point to the third-party/lib directory in your pentaho project. Note that this must be an absolute path. For example, my DEFAULT_LIB_PATH value is e:/workspace_1.6/pentaho/third-party/lib.
2. Add test-lib jars to Build Path
If the following jars are not present in your buildpath, then the test cases will complain of "ClassDefNotFound" problems :
...
This jar can be found in the [PentahoDoc:pentaho_project]/third-party/test-lib directory. You add it to your build path in Eclipse through the Project Properties dialog.
3. Modify the hibernate.cfg.xml File
The hibernate.cfg.xml file has replacement variables in it that get replaced when a server build is performed. For a standalone run, we need to fill in these variables manually.
This file can be found in [PentahoDoc:pentaho_project]/server/pentaho/res/hibernate/hsqldb/hibernate.cfg.xml. I am assuming you are using the default Hypersonic server repository. If your server repository is some other RDBMS flavor, then make sure you update the appropriate file.
...
This file gets copied into the classes directory when the server's Java files are compiled, so make sure that the file that is in the classes directory has the proper values. That is the copy of the file that the standalone session will read and run with. The path to the classes directory in Eclipse is [PentahoDoc:pentaho_project]/build/pentaho-classes.
4. Allow Anonymous Access to the Repository
We have removed security from the standalone execution for JUnit tests. So in order to get the repository to ignore any ACLs that are set, we need to modify the pentaho.xml configuration file.
This file can be found in [PentahoDoc:pentaho-solutions]/system/pentaho.xml.
Open this file, and replace the string com.pentaho.security.acls.voter.PentahoBasicAclVoter with com.pentaho.security.acls.voter.PentahoAllowAllAclVoter.
5. Add vmarg to Eclipse Run Configuration
The last change is to add a special vm argument to your run configuration for the JUnit test, that will tell the engine to use SimpleJNDI classes instead of looking for a web container's JNDI implementation.
...
That should be it! You can now run your JUnit test case from the run configuration you created in the last step. If you run into any other gotchas concerning this exercise, please post to our BI Server forum, or update the doc here.
Troubleshooting
Using the RDBMS-based Solution Repository
If you are using the RDBMS solution repository versus the file-based solution repository, note that the solutions you are executing in the JUnit test are those that were last loaded into the repository, since the JUnit test cases do not refresh the solution repository. If you want to refresh the solution repository while running your cases, I suggest you have a server running parallel to your test case run, and refresh through the Demo PCI Admin page.