Integration testing can be painful enough under the best of circumstances. Confusion around where data comes from, when it should be deleted, rolled back or committed can derail the even the best laid plans. (This is especially true in more complicated projects that involve multiple datasources, that are managed outside the GORM.)

To better manage testing, we (ALTERthought) classify the persistent data to be used in our integration tests into two categories: Fixture Data and Dependent Data …

Fixture Data is data that is pertinent to the test case in particular. Data is considered to be Fixture Data if the following core conditions are true:

• The data is represented by a Domain Object in your system
• The data is writable (create/update/delete)

Fixture Data should be provisioned in one of the following ways:

1. Through a provisioning tool like DBUnit
2. Explicitly in the TestCase setUp()

NOTE: The decision as to whether we provision data using a tool like DBUnit or ‘locally’ in the TestCase setUp() is largely based on the complexity of Domain relationships. The more complicated the Domain Object graph, the more likely we are to use DBUnit to set up the data relationships. This has proven particularly true on projects where we must integrate with legacy databases that are highly normalized, and/or we have multiple datasources. Test fixtures for simple data can easily be provisioned in the setUp() method.

Upon test case completion, any Fixture Data that was added to the system should be removed, leaving the database in a clean state (see The Clean Slate Principle), containing only Dependent Data. Data should be removed in one of the following ways:

1. Through DBUnit processing
2. In the TestCase tearDown()
3. As part of the transactional TestCase rollback

NOTE: It is generally discouraged to explicitly remove the Dependent Data in the test method themselves! Unexpected test case errors can leave your DB in an unstable state with partially populated data.

Dependent Data is data that must be present in order for your test environment to simulate the real world, but is largely tangential to the test cases at hand. Ex: A code table containing the 50 US states, valid zip codes, etc.

Data is considered dependent data if all of the following conditions are true:

• The data is tangential to the test cases at hand
• The data in question is read only. Your test cases will never update or delete the data in question.
• The data can safely live in the DB between test cases.

Dependent data should be provisioned in SQL scripts that are run prior to any tests as part of the environment setup. Once it has been provisioned it need not be re-provisioned for every individual test case.

OK, that’s it! It may seem like obvious advice, but establishing a few simple rules can go a long way towards making testing of your next Grails app much less painful. Subsequent posts will talk a bit about using tools like dbunit to help achieve your testing goals, testing with multiple datasources, as well as advice/hints on testing the various components of a Grails app.

Technorati Tags: grails tests, integration testing, unit testing

Its happened to all of us, a test that was working just fine, suddenly starts failing because the test database was left in an unstable state. Enter the Clean Slate Principle.

Grails integration tests should endeavor to follow a simple rule:

Leave the database in the state in which you found it.

In other words, if your tests perform any write operations on your datasource(s) (Create/Update/Delete) they are responsible for undoing said operation upon test completion.

This ‘Clean Slate Principle’ applies to Test Cases as a we as Test Methods within Test Cases… i.e., if a Test Method inserts a row into the DB as part of a test, it should be removed upon completion (regardless of success or failure).

Subsequent posts will discuss approaches for accomplishing this, as well as the types of pre-existing test data and techniques for provisioning. Until then, keep your slate clean!

Technorati Tags: grails tests, integration testing, unit testing

GRANT ALL PRIVILEGES ON MyDb.* to 'chinnu'@'%' WITH GRANT OPTION;

While % means any host, you probably did not see the behavior you expected.

MySQL performs access control in two stages. First, it tries to connect you with the username/password provided. Next, it checks if you have the privileges to perform your request. Entries in tables user, db and host of mysql database are used for access control.

Lets say this is our user table:

----------------------------------------------
Host      |  User
----------------------------------------------
%         |  root
%         |  chinnu
localhost |  root
localhost |  
----------------------------------------------

% in Host means ‘any host’ and blank in User means any user or anonymous user. Note that the value % is less specific when compared to value localhost. MySQL, when performing access control, sorts this table with the most-specific Host at the top. So, we have something like

-----------------------------------------
Host      |  User
-----------------------------------------
localhost |  root
localhost |   
%         |  chinnu
%         |  root
------------------------------------------

When chinnu tries to login from localhost, there are two matching rows. Guess what, the first match wins. This means that chinnu is effectively logged in as an anonymous user. The anonymous user may not have privileges for MyDb, hence the access denied errors.

How to verify?
If you managed to connect execute SELECT CURRENT_USER(). If you get result as @localhost and not chinnu@localhost, you have the issue described above.

How to solve this?
Solution-1: Grant privileges for ‘chinnu’@'localhost’ in addition to ‘chinnu’@'%’
Solution-2: Just get rid of the anonymous user.

Technorati Tags: mysql