This decision has been migrated to the Technical Council's Decision Log as part of a consolidation effort. See: DR-000025 - Karate API Integration Tests Implementation Guidelines
Some bugs can only be discovered by integrating modules together. It is challenging to identify these on an ongoing basis.
Some integration tests were already implemented. They use Postman collections. They are simple to write but harder to maintain.
It can be challenging to express more complex scenarios. Many of which were contributed by ThunderJet team.
ThunderJet teams has considered a range of tools and recommend Karate tool.
No alternative proposals has been submitted therefore Karate framework is preferred method for creating API integration tests in 2020.
API Integration Test Goal
- Automated regression
- Cross module interaction
- Validate Producer/Consumer relationship
- No mock objects
QA Goals for 2021
Move testing activities to teams scratch environments
Build API Integration Test Coverage (Karate framework)
Implement UI Integration Test (New BigTest) - 109 test cases
Implement manual sprint regression using testing community
Implement UAT events using SIG resources
PO to complete specs for performance acceptance test
Implement performance acceptance test
Extend BugFest time frame (Approved)
- Identify most important business flows
- Add test case to cover a bug condition
- Don't write tests for all possible conditions
Please note that the intent is not to replace rest assured/junit with karate but instead to get the benefits of both approaches
Create tests for new features
- Review if new feature has important business workflows and include test creation for these workflows into estimates
- Features are all ranked and it should determine if tests have to be created
- SM need to drive NFR and make sure that Karate tests are scheduled into Sprints
Test plan creation and estimation
- Before the end of R1 teams have to analyze existing API and identify important business flows and created stubs for them.
- Create Jira tickets for implementation of this tests.
- Create an estimate for each Jira ticket
- Evaluate each workflow based on downstream dependencies
- FAT-145Getting issue details... STATUS
- FAT-146Getting issue details... STATUS
Coverage calculation, reporting
- Coverage defined as % of implemented test cases to total test case count.
- Coverage will be calculated and reported by Jenkins pipeline
Test execution before and after PR
- Part of acceptance criteria - execute Katate tests before PR
- Deploy module in Scratch env. and run applicable tests
- Module changes and test changes are merged at the same time
- Test will be run automatically after PR in Jenkins pipeline the next day:
These pipelines are currently broken - - FOLIO-2982Getting issue details... STATUS
Changes to DOD
- Every team should adjust DOD to require API Integration Tests
Depreciation of Postman tests
- Mostly affects Spitfire and Thunderjet
- Continue to use Postman tests if team doesn't have desire to switch
- Passing tests are required by acceptance criteria
- Postman test pipeline must be:
- have no failures
- Defer decision when to deprecate these tests.
How to evaluate for success
Implementation Tracking Page: Karate API Integration Testing
Proposed Action Items
- Each team should change definition of done to make API integration tests required
- All new BE features must include Karate tests.
- R1 Goal: Each team has to create a test plan for existing API interfaces
- R1 Goal: Each team should provide estimates for the test plan. Estimates will be presented at the Capacity Planning meeting so that this work can be officially scheduled into sprints.
|Tech Leads Meeting notes|
|2020-05-27 Meeting notes||Karate Integration Tests PoC - Q&A|
|2020-08-05 Meeting notes||Implementation of Karate tests|
GitHub repo and documentation: https://github.com/folio-org/folio-integration-tests
Karate resources are at the bottom of README.md
Karate API Integration Testing implementation tracking page
Are Karate tests required for software libraries like https://github.com/folio-org/folio-isbn-util that don't depend on any other FOLIO code?
Are Karate tests required for modules like https://github.com/folio-org/mod-courses that depend on a database only but do not depend on any other FOLIO module?
It would help me to follow this decision if there was a clear summary of the decision somewhere, e.g. all teams must write API integration tests using Karate for all new endpoints
How can a team execute API Integration tests prior to a draft pull request ( https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests ) or a regular pull request that is opened for several developers to collaborate on new code?
By deploying modules in a scratch dev environment.
At that time the code is not yet written because the pull request is opened before any code is written or before the code is complete. How can the scratch environment run code that doesn't exist or isn't complete?