[Mondrian] Running the JUnit tests
Patrick Leckey
patl at seewind.com
Tue Mar 20 16:29:20 EDT 2012
Make sense.
I'll explain the route I was going, and you may be able to suggest better testing changes for me to make … :)
We're working on extending closure tables so that if the peer hierarchy's primary key isn't the same as the closure table's child column, it will add an extra join through the fact table so that these types of closures can still be rendered in SQL. I've got the change working, and have the tests stubbed, but got stumped on how to use the existing schema to test.
What I did was add 2 columns to the "store" table - employee_id and supervisor_id, which are the employee id and supervisor id of the store manager. I then added this dimension to the FoodMart.xml in order to test:
<Dimension name="Store Managers">
<Hierarchy hasAll="true" allMemberName="All Managers"
primaryKey="store_id" primaryKeyTable="employee"
name="Manager">
<Table name="employee"/>
<Level name="Employee Id" type="Numeric" uniqueMembers="true"
column="employee_id" parentColumn="supervisor_id"
nameColumn="full_name" nullParentValue="0">
<Closure parentColumn="supervisor_id" childColumn="employee_id">
<Table name="employee_closure"/>
</Closure>
<Property name="Marital Status" column="marital_status"/>
<Property name="Position Title" column="position_title"/>
<Property name="Gender" column="gender"/>
<Property name="Salary" column="salary"/>
<Property name="Education Level" column="education_level"/>
<Property name="Management Role" column="management_role"/>
</Level>
</Hierarchy>
</Dimension>
And added a DimensionUsage for it in the Store cube with a foreignKey.
It certainly does seem like a "mash up" in FoodMart, I just couldn't think of any way it would be relevant to that schema - but it is definitely relevant to our implementation. That's the best I could come up with.
If you can think of a way to test that without modifying the schema / data, I'd owe you several beers.
I'll take a look at the TestContext methods you mentioned as well.
Thanks,
Pat
On 2012-03-20, at 4:17 PM, Julian Hyde wrote:
> 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.
>
> Julian
>
>
> On Mar 20, 2012, at 11:18 AM, Patrick Leckey wrote:
>
>> Hi,
>>
>> 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?
>>
>> Thanks,
>> Pat
>>
>> 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
>>> Oracle/MySQL/Greenplum/MsSQL.
>>>
>>> Here's the cotnents of my mondrian.properties file.
>>>
>>> # native stuff
>>> mondrian.native.crossjoin.enable=true
>>> mondrian.native.topcount.enable=true
>>> mondrian.native.filter.enable=true
>>> mondrian.native.nonempty.enable=true
>>> mondrian.rolap.groupingsets.enable=true
>>> #agg stuff
>>> mondrian.rolap.aggregates.Use=false
>>> mondrian.rolap.aggregates.Read=false
>>> # naming stuff
>>> mondrian.olap.SsasCompatibleNaming=false
>>> # data stuff
>>> mondrian.foodmart.jdbcURL=jdbc:oracle:thin:foodmart/foodmart@//:1521/XE
>>> mondrian.foodmart.jdbcUser=foodmart
>>> mondrian.foodmart.jdbcPassword=foodmart
>>> mondrian.jdbcDrivers=oracle.jdbc.OracleDriver
>>>
>>> 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".
>>>
>>> Luc
>>>
>>> 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.
>>>>
>>>> Thanks,
>>>> Pat
>>>> _______________________________________________
>>>> Mondrian mailing list
>>>> Mondrian at pentaho.org
>>>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>> _______________________________________________
>>> Mondrian mailing list
>>> Mondrian at pentaho.org
>>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>
>> _______________________________________________
>> Mondrian mailing list
>> Mondrian at pentaho.org
>> http://lists.pentaho.org/mailman/listinfo/mondrian
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
More information about the Mondrian
mailing list