[Mondrian] Running the JUnit tests
jhyde at pentaho.com
Tue Mar 20 16:17:13 EDT 2012
Changes to FoodMart.xml are discouraged; changes to FoodMart.sql are strongly discouraged.
Here's the rationale.
FoodMart.xml has become a cat's breakfast of various changes that exist just for one or two test cases. It was originally intended to be an example of how to write a Mondrian schema -- and now it's almost an example of how not to!
When you change FoodMart.sql, everyone who has loaded it into a database has to remember to re-load it. If they don't remember, they get very puzzling test failures. There are redundant copies of it for Derby and Access (I think). FoodMart.sql is a big file, even when compressed, and it chews up a bunch of space in perforce (now git) to store the revision, and bandwidth to pull the new change.
Rather than changing FoodMart.xml, we tend to write test cases that make small variations on the schema. See how BasicQueryTest.testDimWithoutAll() calls TestContext.withSchema(). TestContext.create() is even better.
Rather than changing FoodMart.sql, I generally re-use existing columns.
If that is not possible, there is also CsvDBTestCase. I don't use it often, but it is very powerful. It creates tables based on a CSV file, and drops them at the end of the test.
On Mar 20, 2012, at 11:18 AM, Patrick Leckey wrote:
> So in the course of writing some tests, we've had to make changes to FoodMart (added 2 columns to the "store" table, and added a new dimension), in order to properly test the new closure table behaviour we're working on.
> Couple of questions:
> 1) Are changes to FoodMart SQL OK? (as long as they don't break any other tests, of course)
> 2) There are about 17 tests that fail with changes to the FoodMart.xml schema (addition of another dimension). Is there an easy way to update the *.ref.xml files with the new discover query results, or do you pretty much copy & paste the results of actually running those queries?
> On 2012-03-15, at 11:38 AM, Luc Boudreau wrote:
>> That's one of our skeletons in the closet. The test suite has some
>> failures on PgSQL. We don't officially support PgSQL, mostly because
>> of a lack of community interest. Seems like everyone uses
>> Here's the cotnents of my mondrian.properties file.
>> # native stuff
>> #agg stuff
>> # naming stuff
>> # data stuff
>> I personally run the test suite against MySQL and Oracle. It gives me
>> a good enough coverage. Not all tests ared designed to run against all
>> databases, so it is important to test all changes against at least two
>> of the official supported DBs.
>> To run the test suite, I usually run it in Eclipse (launch from
>> mondrian.test.Main). From ant, I'm not exactly sure what are the exact
>> targets to run, but I can guess you will need to setup things by
>> running "ant" then call "ant test".
>> On Wed, Mar 14, 2012 at 6:17 PM, Patrick Leckey <patl at seewind.com> wrote:
>>> We're trying to get our CI box to build and test our local working copies of Mondrian, but we're having some issue with the tests.
>>> We run PostgreSQL as a back-end and so we're setting up the tests to run against that.
>>> Currently our Jenkins job executes:
>>> - Drop the current foodmart database
>>> - Run the load-foodmart ant task
>>> - Run the junit-main ant task
>>> This is generating different results from the tests we see run on the public Pentaho CI server. We get an exception right off the bat (form the PG JDBC driver) saying it can't login as "bogususer". Then a lot of the output looks similar, and the jobs hang - no processes running on the PG server, but JUnit does not complete.
>>> If we change the junit-main task to the test task, it seems to complete but unlike the 8 failures and 0 errors on Pentaho CI, we get 24 failures and 3 errors. Checking the PostgreSQL logs, it seems to mostly be SQL syntax errors (and the "bogususer" error).
>>> I do notice the Pentaho CI build runs the tests against MySQL and not PostgreSQL. Are they designed to only be run against MySQL? If I threw JBoss on our CI box, could we run them against the Derby DB? (I mostly just don't want to setup a MySQL instance on that box)
>>> test.properties and mondrian.properties are both setup in the Jenkins workspace folder and found by the build, all info in them looks correct (mondrian.test.connectString is picked up, etc.).
>>> This is being run on a clean check-out of //open/mondrian from this morning, no changes at all except to the test.properties and mondrian.properties files.
>>> Mondrian mailing list
>>> Mondrian at pentaho.org
>> Mondrian mailing list
>> Mondrian at pentaho.org
> Mondrian mailing list
> Mondrian at pentaho.org
More information about the Mondrian