Failing tests testColumnConstraints + location integration / roundtrip tests

[Martin van den Bemt <ml...@mvdb.net>]

Hi Tom,

All (if not almost) all tests are failing on testColumnConstraints.
It expects an unquoted default value now (which seem to relate to your changes on defaultvalues)
This is a line from one of the tests :
"    \"COL_NOT_NULL_DEFAULT\" FLOAT DEFAULT '-2.0' NOT NULL,\n"+

I also would like to move the integration type tests to another source directory, so it is easier to seperate real unit tests from the one that depend on something external (esp since most of them will always fail by default).
I was thinking in the lines of src/iutest or src/dbtest.

Mvgr,
Martin

Re: Failing tests testColumnConstraints + location integration / roundtrip tests

[Thomas Dudziak <to...@gmail.com>]

On 12/23/05, Martin van den Bemt <ml...@mvdb.net> wrote:

> > Mhm, methinks the line is a bit blurry here. After all DdlUtils is
> > specifically meant to work against databases, so you could rightfully
> > call these tests unit tests.
>
> Think we just have different definitions of what a unit test should cover :)

As I said, the line is a bit blurry. Normally you would just say
'create database' and then check what's in the database. But that is a
bit difficult to do generically, so I combined that with the reverse
direction of reading back a database (-> roundtrip).
Likewise, for testing that data insertion works you need a database to
insert into, so you would combine that with database creation. And
voila, you get what the roundtrip tests are currently doing.
Also, allmost every test currently defined for DdlUtils is rather an
integration test than a unit test because they test the functionality
of DdlUtils rather then individual methods. But I think that is ok
because DdlUtils is a somewhat small library, and testing individual
methods or small classes might be difficult.

> But I agree that we can move them to a
> > separate place, though I'd prefer still in the test source tree (e.g.
> > to a separate package). Another source tree makes the build process
> > more complicated, and there are dependencies from the tests against
> > the databases to the other tests.
>
> Does the dbtest package sound ok to you ?

Let me finish the tests first, and then we can rename the package to
whatever we want, e.g. org.apache.ddlutils.roundtrip or something ?

Tom

Re: Failing tests testColumnConstraints + location integration / roundtrip tests

[Martin van den Bemt <ml...@mvdb.net>]

> 
> Mhm, methinks the line is a bit blurry here. After all DdlUtils is
> specifically meant to work against databases, so you could rightfully
> call these tests unit tests. 

Think we just have different definitions of what a unit test should cover :)

But I agree that we can move them to a
> separate place, though I'd prefer still in the test source tree (e.g.
> to a separate package). Another source tree makes the build process
> more complicated, and there are dependencies from the tests against
> the databases to the other tests.

Does the dbtest package sound ok to you ?

Mvgr,
Martin

Re: Failing tests testColumnConstraints + location integration / roundtrip tests

[Thomas Dudziak <to...@gmail.com>]

On 12/23/05, Martin van den Bemt <ml...@mvdb.net> wrote:

> When I look at the TestRoundTripDerby and the RoundTripTestBase, I cannot see anything specific that you are just targetting the io package, unless you mean the part where you use the DataReader.
> That testcoverage that is achieved in the io package is merely a side effect of these integration tests. Probably unit testing DataReader needs some mocks to keep it a unit test (same as eg platform.* should have some mocks, where eg a connection is needed (like in fetch).
>
> In my opinion we should treat any class that we feed a realtime database connection as an integration test and move them to a different package and in my preference source tree.
>
> Just to be clear TestDatabaseIO and TestDataReader are of course in the right place.
>

Mhm, methinks the line is a bit blurry here. After all DdlUtils is
specifically meant to work against databases, so you could rightfully
call these tests unit tests. But I agree that we can move them to a
separate place, though I'd prefer still in the test source tree (e.g.
to a separate package). Another source tree makes the build process
more complicated, and there are dependencies from the tests against
the databases to the other tests.

> > Do you plan to add other tests (right now, the roundtrip test do:
> > create, insert data, fetch data, read model from db and check it) ?
>
> Not specifically, but to maintain readability of classes (esp when testcases get big), I tend to create separate testcases. Subpackaging is not needed right away, we can do that when there is a need to.

Agreed.

> > One thing that has to be added yet is testing without delimiters.
>
> Axion doesn't like delimiters :)

Yep, I saw that. Strange that their SQL grammar does not cover that,
wouldn't be too difficult (just changing one rule).

> Indeed and just noticed (to my surprise) there is actually some development going on axion, so who knows some things get fixed..  (i'll see if I can file an issue for the lack of support on getImportKeys)

Sounds good!

Tom

Re: Failing tests testColumnConstraints + location integration / roundtrip tests

[Martin van den Bemt <ml...@mvdb.net>]

Thomas Dudziak wrote:
> On 12/22/05, Martin van den Bemt <ml...@mvdb.net> wrote:
> 
> 
>>Ah ok.. You are in Germany right ?
> 
> Yes, in Berlin.
I am in Breda, in the south of The Netherlands. In short : not a driving distance :)

> 
> 
>>I think the io test package will actually mix too many concerns if we do that, since most classes in io can be unit tested (integration tests have nothing to do with io unit tests). So at least we should consider a new package name, with probably subpackages like derby, axion, hsqldb, oracle, since I don't think we'll going to end up with 1 testcase per database and things (in my opinion) will get quite messy otherwise.
> 
> 
> Why do you think that is necessary? If you look into class
> RoundtripTestBase, you'll see what I intend to test. Most if not all
> of these will look like the tests already in TestRoundtripDerby,
> though I expect I can refactor the tests later on to make them even
> shorter.

When I look at the TestRoundTripDerby and the RoundTripTestBase, I cannot see anything specific that you are just targetting the io package, unless you mean the part where you use the DataReader.
That testcoverage that is achieved in the io package is merely a side effect of these integration tests. Probably unit testing DataReader needs some mocks to keep it a unit test (same as eg platform.* should have some mocks, where eg a connection is needed (like in fetch).

In my opinion we should treat any class that we feed a realtime database connection as an integration test and move them to a different package and in my preference source tree.

Just to be clear TestDatabaseIO and TestDataReader are of course in the right place.

> Do you plan to add other tests (right now, the roundtrip test do:
> create, insert data, fetch data, read model from db and check it) ?

Not specifically, but to maintain readability of classes (esp when testcases get big), I tend to create separate testcases. Subpackaging is not needed right away, we can do that when there is a need to.

> One thing that has to be added yet is testing without delimiters.

Axion doesn't like delimiters :)

> 
>>About Axion : roundtripping will not work that well (working on axion currently), since I get some not supported exceptions when importing the model from the database itself.
> 
> 
> Mhmm, not good, but not DdlUtils fault either. When we document that
> properly, this should be no problem ?

Indeed and just noticed (to my surprise) there is actually some development going on axion, so who knows some things get fixed..  (i'll see if I can file an issue for the lack of support on getImportKeys)

Mvgr,
Martin

Re: Failing tests testColumnConstraints + location integration / roundtrip tests

[Thomas Dudziak <to...@gmail.com>]

On 12/22/05, Martin van den Bemt <ml...@mvdb.net> wrote:

> Ah ok.. You are in Germany right ?

Yes, in Berlin.

> I think the io test package will actually mix too many concerns if we do that, since most classes in io can be unit tested (integration tests have nothing to do with io unit tests). So at least we should consider a new package name, with probably subpackages like derby, axion, hsqldb, oracle, since I don't think we'll going to end up with 1 testcase per database and things (in my opinion) will get quite messy otherwise.

Why do you think that is necessary? If you look into class
RoundtripTestBase, you'll see what I intend to test. Most if not all
of these will look like the tests already in TestRoundtripDerby,
though I expect I can refactor the tests later on to make them even
shorter.
Do you plan to add other tests (right now, the roundtrip test do:
create, insert data, fetch data, read model from db and check it) ?
One thing that has to be added yet is testing without delimiters.

> About Axion : roundtripping will not work that well (working on axion currently), since I get some not supported exceptions when importing the model from the database itself.

Mhmm, not good, but not DdlUtils fault either. When we document that
properly, this should be no problem ?

Tom

Re: Failing tests testColumnConstraints + location integration / roundtrip tests

[Martin van den Bemt <ml...@mvdb.net>]

Thomas Dudziak wrote:
> On 12/22/05, Martin van den Bemt <ml...@mvdb.net> wrote:
> 
> 
>>All (if not almost) all tests are failing on testColumnConstraints.
>>It expects an unquoted default value now (which seem to relate to your changes on defaultvalues)
>>This is a line from one of the tests :
>>"    \"COL_NOT_NULL_DEFAULT\" FLOAT DEFAULT '-2.0' NOT NULL,\n"+
> 
> 
> Yes, you're right. I'll fix that when I add some more tests later
> today (doing a bit of OJB work at the moment).

Ah ok.. You are in Germany right ?

> 
> 
>>I also would like to move the integration type tests to another source directory, so it is easier to seperate real unit tests from the one that depend on something external (esp since most of them will always fail by default).
>>I was thinking in the lines of src/iutest or src/dbtest.
> 
> 
> My plan was to put all those tests into the package
> org.apache.ddlutils.io, and add guards to check against which live
> database the tests are currently being executed (if any). Thus, no
> confiuration in the build file is necessary, tests not for the current
> database simply won't be executed. And if no live database is
> configured at all, none of these tests will be executed.
> I wanted to put that in once I adapt the tests for Derby to another
> database (probably Hsqldb or Axion) which should be at the weekend.

I think the io test package will actually mix too many concerns if we do that, since most classes in io can be unit tested (integration tests have nothing to do with io unit tests). So at least we should consider a new package name, with probably subpackages like derby, axion, hsqldb, oracle, since I don't think we'll going to end up with 1 testcase per database and things (in my opinion) will get quite messy otherwise.

About Axion : roundtripping will not work that well (working on axion currently), since I get some not supported exceptions when importing the model from the database itself.

Mvgr,
Martin

Re: Failing tests testColumnConstraints + location integration / roundtrip tests

[Thomas Dudziak <to...@gmail.com>]

On 12/22/05, Martin van den Bemt <ml...@mvdb.net> wrote:

> All (if not almost) all tests are failing on testColumnConstraints.
> It expects an unquoted default value now (which seem to relate to your changes on defaultvalues)
> This is a line from one of the tests :
> "    \"COL_NOT_NULL_DEFAULT\" FLOAT DEFAULT '-2.0' NOT NULL,\n"+

Yes, you're right. I'll fix that when I add some more tests later
today (doing a bit of OJB work at the moment).

> I also would like to move the integration type tests to another source directory, so it is easier to seperate real unit tests from the one that depend on something external (esp since most of them will always fail by default).
> I was thinking in the lines of src/iutest or src/dbtest.

My plan was to put all those tests into the package
org.apache.ddlutils.io, and add guards to check against which live
database the tests are currently being executed (if any). Thus, no
confiuration in the build file is necessary, tests not for the current
database simply won't be executed. And if no live database is
configured at all, none of these tests will be executed.
I wanted to put that in once I adapt the tests for Derby to another
database (probably Hsqldb or Axion) which should be at the weekend.

Tom