ga4gh / ga4gh/openapi-test-runner

Validate server S3 storage functionality

Open
#5 0 comments 1 reaction 0 assignees View on GitHub
Dominant language
HTML
Stars
5
Forks
6
PR merge metrics
No merged PRs in 30d

Description

A suggested feature add-on was to include the S3 storage functionality in the compliance suite to make it versatile instead of being focused primarily on the API side validation. This would allow for cloud development validation for TES servers. These test cases would be termed as **"functional"** test cases, while the existing ones would all be referred as the **"logical"** test cases.

The methodology followed is -
1. Get the Server S3 storage credentials and pass them in a `config` file inside compliance suite.
2. Access the S3 storage via `boto3` SDK.
3. Create a new bucket for compliance testing.
4. Write a functional test case involving the S3 file storage.
5. Validate the result via `Get Task` and the output files inside S3 to check if the TES server behaved properly.

This feature has already been worked upon and the code is inside the `feature/s3-storage` branch. Majority of the work is done (i.e. till step 4) The approach used in the current code calculates the result of output files in runtime. However, it was discussed that this is not needed as we can refer the existing pre-stored solutions of a Test and validate the result against them. Therefore, no need to calculate the results in runtime.

Due to lack of time as the GSoC was ending its duration, the feature could not be completed, though its already in a working state for simple functional testcases. To complete the feature, the additional changes required would be as follows -
1. Modify the test case to involve some output files.
2. Store the expected correct result of this test case already.
2. Validate the output files generated via the actual TES server implementation against the stored results.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the existing code in the feature/s3-storage branch and the compliance-suite config file, then trace how boto3 accesses the test bucket and how functional cases validate TES results. Replace runtime result calculation with stored expected results, add output files to a test case, and compare the generated S3 files with those stored results.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, python
Domain
cloud, testing-qa
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.