API Karate tests implementation - Tech Debt (FAT-892)

[UXPROD-3394] Tech Debt: Create EDGE-RTAC tests with Karate - R1 2022 Created: 01/Nov/21  Updated: 06/Jan/22  Resolved: 06/Jan/22

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Lotus (R1 2022)
Parent: API Karate tests implementation - Tech Debt

Type: New Feature Priority: P2
Reporter: Holly Mistlebauer Assignee: Adesh Singh
Resolution: Done Votes: 0
Labels: NFR, quality_control, tech-debt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
is defined by EDGRTAC-45 Create Karate test for Edge-RTAC: Fo... Closed
is defined by EDGRTAC-46 Create Karate test for Edge-RTAC: Fo... Closed
is defined by EDGRTAC-47 Create Karate test for Edge-RTAC: Fo... Closed
is defined by EDGRTAC-48 Create Karate test for Edge-RTAC: Fo... Closed
is defined by EDGRTAC-49 Create Karate test for Edge-RTAC: If... Closed
Relates
relates to FAT-1128 Edge module tests should use the targ... Open
relates to FAT-161 mod-users-bl: Setup API Karate tests ... Open
relates to FAT-165 mod-users-bl: Create test plan to cov... Open
relates to FAT-175 mod-users-bl: Implement API Karate te... Open
relates to UXPROD-3138 Tech Debt: Create MOD-USERS tests wi... Closed
relates to UXPROD-3347 Tech Debt: Create MOD-CIRCULATION tes... Closed
relates to UXPROD-3348 Tech Debt: Create MOD-INVENTORY tests... Closed
relates to UXPROD-3393 Tech Debt: Create EDGE-PATRON tests ... Closed
Epic Link: API Karate tests implementation - Tech Debt
Back End Estimate: XL < 15 days
Back End Estimator: Holly Mistlebauer
Development Team: Prokopovych
PO Rank: 100

 Description   

Create Karate tests for EDGE-RTAC module.



 Comments   
Comment by Adesh Singh [ 02/Dec/21 ]

Api key issue

we can generate random API keys  but  The problem is that the secret store on the hosting side needs to be aware of the information in them.

we can not hardcode diku/diku tenant, this creates a coupling that could be challenging in the future. These tests shouldn’t be aware of the diku tenant at all..
 

Comment by Khalilah Gambrell [ 09/Dec/21 ]

Adesh Singh, this feature is blocked due to the api key issue? Can you direct me to the story that addresses this issue?

Comment by Adesh Singh [ 10/Dec/21 ]

Khalilah Gambrell 

My Apologies , i have started working on it & forgot to update the status .
i blocked it previously due to above mentioned issue . After discussing with Marc Johnson & other teams who have worked on similar-modules we decided to go with "Diku" tenant only, as we dont have any other option as of now . 

Comment by Marc Johnson [ 10/Dec/21 ]

Khalilah Gambrell

this feature is blocked due to the api key issue? Can you direct me to the story that addresses this issue?

After discussing with Marc Johnson & other teams who have worked on similar-modules we decided to go with "Diku" tenant only, as we dont have any other option as of now

There is no issue for addressing this issue. We decided to use the same workaround that others took before us :-/

I think the workaround of using the diku tenant has the unfortunate impact of coupling these tests to the hosted reference environments (meaning they can't be run against a BugFest environment for example) and they change the state of the tenant that folks use for manual testing.

I think this should be resolved. I haven't raised an issue because I don't know who would be responsible for this work. I can raise an issue if that would be helpful?

Comment by Khalilah Gambrell [ 10/Dec/21 ]

Thank you Marc Johnson and Adesh Singh

Comment by Marc Johnson [ 15/Dec/21 ]

Khalilah Gambrell I've created a FAT-1128 Open for this compromise (that predates the Prokopovych work)

Generated at Fri Feb 09 00:31:40 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.