Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Date: Mon, 06 Jul 2009 06:32:40 -0700
From: Rick Hillegas <Richard.Hillegas@Sun.COM>
Subject: Re: [GSoC] Automated Testing for Improved dblook Implementation
In-reply-to: <558af1840907050951w7696cfb5t8c40d415256abe42@mail.gmail.com>
Sender: Richard.Hillegas@Sun.COM
To: derby-dev@db.apache.org
Message-id: <4A51FCF8.5010207@sun.com>
References: <558af1840907050951w7696cfb5t8c40d415256abe42@mail.gmail.com>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)

Hiranya Jayathilaka wrote:
> Hi Folks,
>
> Now that I've reached the final stages of my project to improve dblook 
> I think it's time I start thinking about writing some automated tests 
> for the new and improved dblook implementation. Dag came up with the 
> idea of getting dblook to generate a script against some reference 
> database and then run the script to create a copy of the reference 
> database. Then the copy will be compared with the reference database 
> to verify that all persistent objects like tables and views are 
> properly in place. Eventhough it sounds like lot of work it's 
> certainly doable and I think this is a great way to test dblook. We 
> will probably have to modify the script generated by dblook by filling 
> in the passwords. That should also take place in the automated 
> environment.
>
> I would like to know what the community thinks about this testing 
> strategy. Also I would appreciate if you can provide your own ideas on 
> this issue.
Hi Hiranya,

I think this sounds like a reasonable approach. The recently written 
UpgradeTrajectoryTest does something similar: it compares the metadata 
in Before and After databases. You may get some implementation ideas if 
you glance at that test. Two tricky bits about comparing metadata are 1) 
you need to remap UUIDs, 2) timestamp columns are unstable. 
UpgradeTrajectoryTest.normalizeRow() may help you sort through the 
expected differences.

Hope this helps,
-Rick
>
>
> Thanks,
> Hiranya Jayathilaka
>