You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Alberto Bustamante Reyes <al...@est.tech> on 2019/11/07 15:41:06 UTC

geode-native integration tests

Hi Geode community,

Im curious about the geode-native integration tests. I have seen there are two kind of tests, depending on the framework they are based on. But no one of them are included in the CI executed by travis. Are they executed only as part of the Geode release process?

What is the way of working regarding new tests? I assume that new tests should be written using the new framework. But what about the old ones? Is there any plan to port these test to the new framework? (I suppose that PRs for that are welcome)

What if a PR requires the modification of an old integration test? I suppose that as a general rule, instead of modifying that test case, a new test case in the new framework should be written and then the old one should be removed.

Im missing all this info about the way of working in the CONTRIBUTING.md file, I can include it once this is cleared up.

Thanks!


Alberto B.

RE: geode-native integration tests

Posted by Alberto Bustamante Reyes <al...@est.tech>.
Thanks for the answer Jake, I have sent a PR with the changes. I already know the plans to use concourse instead of travis in the Geode client, I have it in mind, its a good opportunity to learn about concourse.
________________________________
De: Jacob Barrett <jb...@pivotal.io>
Enviado: jueves, 7 de noviembre de 2019 17:50
Para: dev@geode.apache.org <de...@geode.apache.org>
Asunto: Re: geode-native integration tests



> On Nov 7, 2019, at 7:41 AM, Alberto Bustamante Reyes <al...@est.tech> wrote:
>
> Im curious about the geode-native integration tests. I have seen there are two kind of tests, depending on the framework they are based on. But no one of them are included in the CI executed by travis. Are they executed only as part of the Geode release process?

The long term goal is to have geode-native built continuously with along with main java bits. If you are interested in helping with this effort that might speed up the process.

> What is the way of working regarding new tests? I assume that new tests should be written using the new framework. But what about the old ones? Is there any plan to port these test to the new framework? (I suppose that PRs for that are welcome)

Yes all new tests should be written in the new framework. The new framework is a work in progress itself. It it is missing something, add it. If it needs refactoring, refactor it. There is no current plan to bulk convert the old tests, see next response.

> What if a PR requires the modification of an old integration test? I suppose that as a general rule, instead of modifying that test case, a new test case in the new framework should be written and then the old one should be removed.

The old framework should be considered deprecated and obsolete. Make minimal changes as necessary to it. If you make a PR that touches several tests it is reasonable to just update the old integration tests. If your PR would have you changing one or a few of the old tests then please rewrite those tests in the new framework and delete the old. Hopefully over time we won’t have any old tests left.

> Im missing all this info about the way of working in the CONTRIBUTING.md file, I can include it once this is cleared up.

Yes please contribute to the CONTRIBUTING.md!

Thanks,
Jake


Re: geode-native integration tests

Posted by Jacob Barrett <jb...@pivotal.io>.

> On Nov 7, 2019, at 7:41 AM, Alberto Bustamante Reyes <al...@est.tech> wrote:
> 
> Im curious about the geode-native integration tests. I have seen there are two kind of tests, depending on the framework they are based on. But no one of them are included in the CI executed by travis. Are they executed only as part of the Geode release process?

The long term goal is to have geode-native built continuously with along with main java bits. If you are interested in helping with this effort that might speed up the process.

> What is the way of working regarding new tests? I assume that new tests should be written using the new framework. But what about the old ones? Is there any plan to port these test to the new framework? (I suppose that PRs for that are welcome)

Yes all new tests should be written in the new framework. The new framework is a work in progress itself. It it is missing something, add it. If it needs refactoring, refactor it. There is no current plan to bulk convert the old tests, see next response.

> What if a PR requires the modification of an old integration test? I suppose that as a general rule, instead of modifying that test case, a new test case in the new framework should be written and then the old one should be removed.

The old framework should be considered deprecated and obsolete. Make minimal changes as necessary to it. If you make a PR that touches several tests it is reasonable to just update the old integration tests. If your PR would have you changing one or a few of the old tests then please rewrite those tests in the new framework and delete the old. Hopefully over time we won’t have any old tests left.

> Im missing all this info about the way of working in the CONTRIBUTING.md file, I can include it once this is cleared up.

Yes please contribute to the CONTRIBUTING.md!

Thanks,
Jake