Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[#216][#217] test: add e2e integration test framework & metalake integration test #235

Merged
merged 16 commits into from
Aug 30, 2023
Merged

Conversation

xunliu
Copy link
Member

@xunliu xunliu commented Aug 14, 2023

What changes were proposed in this pull request?

e2e integration test framework implementation below function.

  • Create a new integration module, you can execute each integration test code in it.
  • Each test set can start/stop a Graviton Server instance in the local or Github action environment.
  • You can through Graviton Client or HttpClient to connect the Graviton Server instance to test.

Test operation flow

  1. Deploy integration test environment

    ./gradlew clean build
    ./gradlew clean compileDistribution 
    # The `compileDistribution` command will create `distribution/package/...` directory in the Graviton root directory.
    
  2. Execute test units in the integration module.

    • Auto start Graviton Server before the test.
    • Execute your test code at this time.
    • Auto stop Graviton Server after the test.
  3. Manual execution of tests units in GravitonServer debug mode

    • Enable GRAVITON_DEBUG_OPTS envronirment in the graviton-env.conf file.
    • Manual execution ./distribution/package/bin/graviton.sh start
    • Remote debug Graviton Server in the 8000 port (default).
    • Set breakpoint in the Graviton project.
    • Manual execution integration tests unit.

Why are the changes needed?

e2e test provides a real deployment environment to execute integration tests.

  • It can validity test Graviton startup scripts, graviton.conf, graviton-env.sh, and more properties files.
  • It can validity test Catalogs JAR isolated.

Fix: #216, #217

Does this PR introduce any user-facing change?

N/A

How was this patch tested?

Tested in the integration module

@github-actions
Copy link

github-actions bot commented Aug 14, 2023

Code Coverage Report

Overall Project 61.19% 🟢
Module Coverage
server 91.71% 🟢
Files
Module File Coverage
server GravitonServer.java 64.14% 🟢

@xunliu xunliu requested review from jerryshao and yuqi1129 August 14, 2023 12:07
@xunliu
Copy link
Member Author

xunliu commented Aug 15, 2023

@jerryshao Please help me review this PR, thanks.

@xunliu
Copy link
Member Author

xunliu commented Aug 28, 2023

@jerryshao @yuqi1129 Please help me review this PR, thinks.

@xunliu xunliu closed this Aug 29, 2023
@xunliu xunliu reopened this Aug 29, 2023
@jerryshao jerryshao added need backport Issues that need to backport to another branch branch-0.1 labels Aug 29, 2023
public void testLoadMetalake() {
GravitonMetaLake metaLake = client.loadMetalake(NameIdentifier.of(metalakeName));
Assertions.assertEquals(metaLake.name(), metalakeName);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we need to add more failure situations.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, We need to supplement more coverage test cases.
I created a new issue #299 track this issue.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'd better put createMetalake and dropMetalake as a test, not in static start and stop methods.

Copy link
Member Author

@xunliu xunliu Aug 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is because testing the listMetalake() or modifyMetalake() methods first requires the creation of a Metalake.
Put createMetalake() in the static start() methods, It is easy to run each test case separately.
Put dropMetalake() in the static stop() methods, It can safely delete metalak to run each test case separately.
This way it can support running all tests or run a single test.

@jerryshao jerryshao changed the title [#216][#217] e2e integration test framework & metalake integration test [#216][#217] test: add e2e integration test framework & metalake integration test Aug 30, 2023
@jerryshao jerryshao merged commit 29ba4a9 into apache:main Aug 30, 2023
github-actions bot pushed a commit that referenced this pull request Aug 30, 2023
…gration test (#235)

### What changes were proposed in this pull request?

e2e integration test framework implementation below function.

+ Create a new integration module, you can execute each integration test
code in it.
+ Each test set can start/stop a Graviton Server instance in the local
or Github action environment.
+ You can through Graviton Client or HttpClient to connect the Graviton
Server instance to test.

#### Test operation flow

1. Deploy integration test environment
    ```
    ./gradlew clean build
    ./gradlew clean compileDistribution 
# The `compileDistribution` command will create
`distribution/package/...` directory in the Graviton root directory.
    ```
2. Execute test units in the `integration` module.
    + Auto start Graviton Server before the test.
    + Execute your test code at this time.
    + Auto stop Graviton Server after the test.

3. Manual execution of tests units in GravitonServer debug mode
+ Enable `GRAVITON_DEBUG_OPTS` envronirment in the graviton-env.conf
file.
    + Manual execution `./distribution/package/bin/graviton.sh start`
    + Remote debug Graviton Server in the 8000 port (default).
    + Set breakpoint in the Graviton project.
    + Manual execution integration tests unit.

### Why are the changes needed?

e2e test provides a real deployment environment to execute integration
tests.

+ It can validity test Graviton startup scripts, graviton.conf,
graviton-env.sh, and more properties files.
+ It can validity test Catalogs JAR isolated.

Fix: #216, #217 

### Does this PR introduce _any_ user-facing change?

N/A

### How was this patch tested?

Tested in the integration module
@xunliu xunliu deleted the issue-216 branch December 11, 2023 11:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need backport Issues that need to backport to another branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Subtask] e2e integration test framework
3 participants