You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by "ptr.bojko@gmail.com" <pt...@gmail.com> on 2017/12/02 23:40:02 UTC

end2end tests

Hello fellow calcite dev team,

I am building a database with use of calcite framework and decided that
instead of simple unit tests I will go only with integration tests. This is
due the fact that my code only glues the calcite with data and configures
the whole thing decorating with web api and jdbc access (with avatica ;) ).

I have some problems with calcite, possible bugs - some of them in apache
jira for calcite logged already. Those problem are visible through my
tests.

And with that in mind I have an idea for a new maven artifact for calcite -
end to end tests for an example h2 database. Database could have some
tables with data - maybe 100k rows in all tables. Tests with assertj and
its derivatives, something like I've done in my project - see the pastebin
https://pastebin.com/raw/mevih4k6 .

Such test set can help with lowering regressions establishing a common
ground for talking about the calcite behaviour on specific cases (which can
be described through end2end tests).

The tech under such maven artifact can be pretty simple:

   - h2 as a data source, maybe some other
   - one properly complicated json calcite schema
   - some tech for populating h2 with data (just for having data with some
   descriptive language, not a binary format)
   - assertj-db for DSL in tests

What do You think?

Cheers,
Pete

Re: end2end tests

Posted by Julian Hyde <jh...@apache.org>.
Yes, please do.

> On Dec 8, 2017, at 7:13 AM, ptr.bojko@gmail.com wrote:
> 
> I've taken a look into quidem.
> 
> I will log jira for that and assign it to myself, ok?
> 
> On Tue, Dec 5, 2017, 22:26 Julian Hyde <jh...@apache.org> wrote:
> 
>> More tests are always welcome.
>> 
>> I would be wary of adding a new approach (assertj-db). Over time we end up
>> with as many approaches as there are contributors, and so the code becomes
>> hard to maintain. Consider using quidem (see QuidemTest and various .iq
>> files in the code base); it combines assertion-based testing with the
>> simplicity of script-based tests.
>> 
>> This could be added to the “plus” module, where we don’t mind extra
>> dependencies, and don’t mind if the test suite takes a long time.
>> 
>> Julian
>> 
>> 
>>> On Dec 2, 2017, at 3:40 PM, ptr.bojko@gmail.com wrote:
>>> 
>>> Hello fellow calcite dev team,
>>> 
>>> I am building a database with use of calcite framework and decided that
>>> instead of simple unit tests I will go only with integration tests. This
>> is
>>> due the fact that my code only glues the calcite with data and configures
>>> the whole thing decorating with web api and jdbc access (with avatica ;)
>> ).
>>> 
>>> I have some problems with calcite, possible bugs - some of them in apache
>>> jira for calcite logged already. Those problem are visible through my
>>> tests.
>>> 
>>> And with that in mind I have an idea for a new maven artifact for
>> calcite -
>>> end to end tests for an example h2 database. Database could have some
>>> tables with data - maybe 100k rows in all tables. Tests with assertj and
>>> its derivatives, something like I've done in my project - see the
>> pastebin
>>> https://pastebin.com/raw/mevih4k6 .
>>> 
>>> Such test set can help with lowering regressions establishing a common
>>> ground for talking about the calcite behaviour on specific cases (which
>> can
>>> be described through end2end tests).
>>> 
>>> The tech under such maven artifact can be pretty simple:
>>> 
>>>  - h2 as a data source, maybe some other
>>>  - one properly complicated json calcite schema
>>>  - some tech for populating h2 with data (just for having data with some
>>>  descriptive language, not a binary format)
>>>  - assertj-db for DSL in tests
>>> 
>>> What do You think?
>>> 
>>> Cheers,
>>> Pete
>> 
>> 


Re: end2end tests

Posted by "ptr.bojko@gmail.com" <pt...@gmail.com>.
I've taken a look into quidem.

I will log jira for that and assign it to myself, ok?

On Tue, Dec 5, 2017, 22:26 Julian Hyde <jh...@apache.org> wrote:

> More tests are always welcome.
>
> I would be wary of adding a new approach (assertj-db). Over time we end up
> with as many approaches as there are contributors, and so the code becomes
> hard to maintain. Consider using quidem (see QuidemTest and various .iq
> files in the code base); it combines assertion-based testing with the
> simplicity of script-based tests.
>
> This could be added to the “plus” module, where we don’t mind extra
> dependencies, and don’t mind if the test suite takes a long time.
>
> Julian
>
>
> > On Dec 2, 2017, at 3:40 PM, ptr.bojko@gmail.com wrote:
> >
> > Hello fellow calcite dev team,
> >
> > I am building a database with use of calcite framework and decided that
> > instead of simple unit tests I will go only with integration tests. This
> is
> > due the fact that my code only glues the calcite with data and configures
> > the whole thing decorating with web api and jdbc access (with avatica ;)
> ).
> >
> > I have some problems with calcite, possible bugs - some of them in apache
> > jira for calcite logged already. Those problem are visible through my
> > tests.
> >
> > And with that in mind I have an idea for a new maven artifact for
> calcite -
> > end to end tests for an example h2 database. Database could have some
> > tables with data - maybe 100k rows in all tables. Tests with assertj and
> > its derivatives, something like I've done in my project - see the
> pastebin
> > https://pastebin.com/raw/mevih4k6 .
> >
> > Such test set can help with lowering regressions establishing a common
> > ground for talking about the calcite behaviour on specific cases (which
> can
> > be described through end2end tests).
> >
> > The tech under such maven artifact can be pretty simple:
> >
> >   - h2 as a data source, maybe some other
> >   - one properly complicated json calcite schema
> >   - some tech for populating h2 with data (just for having data with some
> >   descriptive language, not a binary format)
> >   - assertj-db for DSL in tests
> >
> > What do You think?
> >
> > Cheers,
> > Pete
>
>

Re: end2end tests

Posted by Julian Hyde <jh...@apache.org>.
More tests are always welcome.

I would be wary of adding a new approach (assertj-db). Over time we end up with as many approaches as there are contributors, and so the code becomes hard to maintain. Consider using quidem (see QuidemTest and various .iq files in the code base); it combines assertion-based testing with the simplicity of script-based tests.

This could be added to the “plus” module, where we don’t mind extra dependencies, and don’t mind if the test suite takes a long time.

Julian


> On Dec 2, 2017, at 3:40 PM, ptr.bojko@gmail.com wrote:
> 
> Hello fellow calcite dev team,
> 
> I am building a database with use of calcite framework and decided that
> instead of simple unit tests I will go only with integration tests. This is
> due the fact that my code only glues the calcite with data and configures
> the whole thing decorating with web api and jdbc access (with avatica ;) ).
> 
> I have some problems with calcite, possible bugs - some of them in apache
> jira for calcite logged already. Those problem are visible through my
> tests.
> 
> And with that in mind I have an idea for a new maven artifact for calcite -
> end to end tests for an example h2 database. Database could have some
> tables with data - maybe 100k rows in all tables. Tests with assertj and
> its derivatives, something like I've done in my project - see the pastebin
> https://pastebin.com/raw/mevih4k6 .
> 
> Such test set can help with lowering regressions establishing a common
> ground for talking about the calcite behaviour on specific cases (which can
> be described through end2end tests).
> 
> The tech under such maven artifact can be pretty simple:
> 
>   - h2 as a data source, maybe some other
>   - one properly complicated json calcite schema
>   - some tech for populating h2 with data (just for having data with some
>   descriptive language, not a binary format)
>   - assertj-db for DSL in tests
> 
> What do You think?
> 
> Cheers,
> Pete