-
Notifications
You must be signed in to change notification settings - Fork 23
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
Add BDD tests for Token Feature to RSTUF API #369
Add BDD tests for Token Feature to RSTUF API #369
Conversation
Codecov ReportPatch and project coverage have no change.
Additional details and impacted files@@ Coverage Diff @@
## main #369 +/- ##
=======================================
Coverage 96.30% 96.30%
=======================================
Files 19 19
Lines 785 785
=======================================
Hits 756 756
Misses 29 29 ☔ View full report in Codecov by Sentry. |
1f5025e
to
ddb8f74
Compare
The functional tests for token is not cross-component and it removes from the umbrella repository. The tests are added to the RSTUF API (PR repository-service-tuf/repository-service-tuf-api#369) This is part of repository-service-tuf#41 Closes: repository-service-tuf#267 Signed-off-by: Kairo de Araujo <[email protected]>
@KAUTH its also related to repository-service-tuf/repository-service-tuf#364 |
* Remove token functional tests The functional tests for token is not cross-component and it removes from the umbrella repository. The tests are added to the RSTUF API (PR repository-service-tuf/repository-service-tuf-api#369) This is part of #41 Closes: #267 Signed-off-by: Kairo de Araujo <[email protected]> * Remove auth from FT Removes the authentication/authorization as part of the Gherkin for the features as it is not a requirement and depends on the setup. The built-in authentication is a explicity feature in the RSTUF API. It simplifies the BDD/Functional Tests for RSTUF It is part of #41 Closes #269 Signed-off-by: Kairo de Araujo <[email protected]> * Remove auth from RSTUF deployment in the FT Remove auth as enabled from the RSTUF API Signed-off-by: Kairo de Araujo <[email protected]> --------- Signed-off-by: Kairo de Araujo <[email protected]>
target_fixture="response", | ||
) | ||
def the_admin_sends_with_invalid_expires_in_payload( | ||
test_client, headers, payload |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those will be calculated with the new values of the new Examples
table, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kairoaraujo am I correct here?
Admin has deployed and bootstrapped RSTUF | ||
|
||
Scenario Outline: Login using RSTUF API | ||
Given the API requester prepares 'data' with <username>, <password>, <scope>, <expires> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: instead of 'data' we could use 'token_data' as it is named in the resource or otherwise 'payload' or 'request_body' (swagger notation)
"""Admin uses HTTP API to generate a token.""" | ||
|
||
|
||
@given("the admin has the admin password", target_fixture="admin_passwd") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not really used anywhere. We can either keep it to make clear that it's an admin user and add a pass
or we might as well remove it since we specify that "Admin uses ...
, so it's safe to assume they have the admin password.
"'write:token' scope", | ||
target_fixture="access_token", | ||
) | ||
def the_admin_has_generated_an_access_token_with_write_token(access_token): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of using the access_token
fixture that has a predetermined set of scopes in the scope
key of data
, we could create a function or fixture that takes the scope as an argument. This way we know that the test is passing because it has that specific required scope (in this case only write:token
) and not because of some other one by accident.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add an invalid expire
in payload
scenario for the login as we do for the generate in
When the admin sends a POST request to '/api/v1/token/new' with invalid 'expires' in 'payload' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we don't check that in our code as well.
We relly that
expires = datetime.fromtimestamp(token.get("exp")) |
@kairoaraujo do you think we want to test that as FT test and/or add a check for expires?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we don't check that in our code as well.
I believe there's validation done in the model here, which is defined for the endpoint here.
If that is indeed the case we can just add this in the improvements task.
return response | ||
|
||
|
||
@then("the admin should get status code '422'") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this the same as
@then("the admin should get status code '422'") |
ddb8f74
to
10074d1
Compare
Rebased |
Sounds good to me, we can create an issue to work on the comments left in this PR. Also need the tests to succeed before merging. |
Fixed the dependencies and tests run. |
a919a90
to
58dd19f
Compare
Rebased |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we don't check that in our code as well.
We relly that
expires = datetime.fromtimestamp(token.get("exp")) |
@kairoaraujo do you think we want to test that as FT test and/or add a check for expires?
target_fixture="response", | ||
) | ||
def the_admin_sends_with_invalid_expires_in_payload( | ||
test_client, headers, payload |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kairoaraujo am I correct here?
58dd19f
to
d325510
Compare
Rebased |
The current BDD Tokens tests are part of integration tests in the RSTUF umbrella repository. This BDD feature test doesn't belong to the integration tests once API Token authentication/authorization (auth) feature is a single component. The BDD test is still valid once it describes very well the expected behavior. This commit adds the test to the API and is part of the repository-service-tuf/repository-service-tuf#41 Closes repository-service-tuf#281 Signed-off-by: Kairo de Araujo <[email protected]>
Fix the tests for tests workflow Signed-off-by: Kairo de Araujo <[email protected]>
d325510
to
3dc4390
Compare
@KAUTH I cannot merge until you give approval as well. |
The current BDD Tokens tests are part of integration tests in the RSTUF umbrella repository.
This BDD feature test doesn't belong to the integration tests once API Token authentication/authorization (auth) feature is a single component.
The BDD test is still valid once it describes very well the expected behavior.
This commit adds the test to the API and is part of the repository-service-tuf/repository-service-tuf#41
Closes #281