[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mysql-internals
Subject:    Re: Testing the Storage Engine API
From:       Nidhi Shrotriya <Nidhi.Shrotriya () Sun ! COM>
Date:       2008-07-15 8:13:50
Message-ID: 487C596E.7090201 () Sun ! COM
[Download RAW message or body]

Hi all,

Amit told me about this thread. Sorry, I am just subscribed now.

I would like to put forward some ideas here that I believe should fall
in the same line of thought.
Please have a look at the very first draft of the framework design
coming out on these lines.
https://inside.mysql.com/wiki/SEATeamPage/SE_API_Testing_Framework

Appreciate your comments.

I also understand it has been tested through its usage in storage
engines and the distribution of tests in /mysql-test contain
-Tests for particular SEs.
-Common set of tests with test wrappers to change the SEs.

Though the organization of tests makes it a bit difficult to say we have
comprehensive standalone engine suits or a complete common set for
different SEs. I believe it needs some effort there too to have it more
streamlined.

Brian mentioned Patrik Galbraith also have some kind of framework in
this regard. It would be great if he could share that with us, so that
to avoid any duplicacy.

Rgds,
nidhi

>
>
> On 26 Jun 2008, at 01:51, Amit k. Saha wrote:
>
>   
>> Hello all,
>>
>> Has there been any efforts so far to test the Storage Engine API?
>>
>> A more detailed version of my query:
>>
>> The Storage Engine API is defined by the "sql/handler.h" file. Various
>> storage engines implement all or some of them to suit their specific
>> needs. That way, some of the API calls might not have been tested at
>> all.  Has there been any efforts to actually test all the API calls in
>> some way? Please note that I am talking about the API *not* the SEs
>> themselves.
>>     
>
> No, we haven't.  It's only tested through its usage in a dozen or so
> storage engines, which is not a very good test.
>
> My best idea at present is to implement a new storage engine (called
> "apitest"?) that has some  concrete, known behavior (some good data,
> lots of known bad data), along with lots of assertions about behavior
> from the server, and then write tests that exercise those behaviors
> from the SQL layer via the normal test suite.
>
> - chad
>
> --
> Chad Miller, Sun Microsystems DB Group   chad@mysql.com   Orlando, Florida, USA
>
>
>
>
>   


-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals?unsub=mysql-internals@progressive-comp.com

[prev in list] [next in list] [prev in thread] [next in thread]