You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Nick Dimiduk <nd...@gmail.com> on 2015/04/01 00:24:31 UTC

Test class and package name conventions

Heya,

Do we have any guidelines for test names or locations? I'm seeing a
hodgepodge of things: classes containing tests being either prefixed or
suffixed with "Test"; test living in the same package as the code under
test or tests living in a separate package named test (i.e., "foo", and
"foo.test"). I also noticed that there's some experimentation with
explicitly defined test suites. Do we have strong opinions here? I'm not
looking for a "grand cleanup" patch (at the moment), just guidelines for
incremental improvements.

My preference:
 - test class names prefixed with Test
 - test classes living in the same package as the code under test (this
giving the option of poking around in package-protected bits from test
while keeping the saucy details locked away from the public API)
 - annotation-based suite definition, so that there's no central place for
managing suite membership (and thus avoiding pedestrian merge conflicts)
 - some distinction between unit tests and integration tests, with the
option to run selectively

-n

Re: Test class and package name conventions

Posted by Julian Hyde <jh...@apache.org>.
It seems easier to run all of the tests in a debugger if they are organized into a suite.

Also, in the suite they are ordered. The quick ones that are more likely to fail are towards the front of the list.

It is true that people forget to add tests to CalciteSuite sometimes.

> On Aug 31, 2018, at 2:04 PM, Vladimir Sitnikov <si...@gmail.com> wrote:
> 
> Julian>Add the test class to the annotation in CalciteSuite.java
> 
> Just wondering: what is the purpose of CalciteSuite at all?
> It happens that a new test is not added to CalciteSuite, and it is
> invisible to CI.
> The test does not get executed, and everybody just assumes the test is fine.
> 
> Could we drop CalciteSuite, and just use **Test.java for execution?
> 
> Vladimir


Re: Test class and package name conventions

Posted by Vladimir Sitnikov <si...@gmail.com>.
Julian>Add the test class to the annotation in CalciteSuite.java

Just wondering: what is the purpose of CalciteSuite at all?
It happens that a new test is not added to CalciteSuite, and it is
invisible to CI.
The test does not get executed, and everybody just assumes the test is fine.

Could we drop CalciteSuite, and just use **Test.java for execution?

Vladimir

Re: Test class and package name conventions

Posted by Julian Hyde <ju...@hydromatic.net>.
Test classes end in "Test" and are put in the "test" package if they test public APIs, the specific package otherwise. Test methods start with "test" and have annotation @Test on the same line. Add the test class to the annotation in CalciteSuite.java.

Julian


> On Mar 31, 2015, at 6:24 PM, Nick Dimiduk <nd...@gmail.com> wrote:
> 
> Heya,
> 
> Do we have any guidelines for test names or locations? I'm seeing a
> hodgepodge of things: classes containing tests being either prefixed or
> suffixed with "Test"; test living in the same package as the code under
> test or tests living in a separate package named test (i.e., "foo", and
> "foo.test"). I also noticed that there's some experimentation with
> explicitly defined test suites. Do we have strong opinions here? I'm not
> looking for a "grand cleanup" patch (at the moment), just guidelines for
> incremental improvements.
> 
> My preference:
> - test class names prefixed with Test
> - test classes living in the same package as the code under test (this
> giving the option of poking around in package-protected bits from test
> while keeping the saucy details locked away from the public API)
> - annotation-based suite definition, so that there's no central place for
> managing suite membership (and thus avoiding pedestrian merge conflicts)
> - some distinction between unit tests and integration tests, with the
> option to run selectively
> 
> -n