-
Notifications
You must be signed in to change notification settings - Fork 10
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
Implementation of the Industry Core (Data Provisioning) Testbed #1159
Comments
Constraints
Scope 2
What's the benefit?
Risks/Dependencies
TODOs.
|
I've updated the description of the feature with results from yesterday ("Gherkin & Cucumber") and @markuskeidl comments. |
Based on the picture, I created a list of the seven test cases as a first proposal. This is similar to parts of the description, so feel free to discard it. 1. EDC Connection |
I had an exchange with one of the developers from the rollout-team that was involved in getting our 100 partners onboard in 2024. He confirmed that we can’t expect most companies to be able to even use a postman-collection or any sort of code/script. Having said that, I would propose to build a simple user-interface that interacts with the Testbed Backend APIs to execute certain test cases. The UI can be used to pass parameters such as the specific test-case, Connector URL, BPNL, Digital Twin ID etc as well as the means to provide the test results as output. More sophisticated users can of course interact with the API directly to trigger test-cases. What remains open is how we secure the Testbed UI & API against misuse. We could e.g. protect it with a simple password or connect it to the Cofinity IdP? What do you think? |
Do it modular in React.js (reusing the shared portal components) so you can be fast and we can integrate in the Industry Core Hub, so people can test their "dataspace components". The only question is how much more work would be to create an UI? Do you have developers that can do it? |
Makes perfectly sense for me. I'll add that as a prerequisite for the UI part. |
I agree that only having an API without an frontend might be a challenge for a lot of new partners. But you also said it yourself, even with the UI you need to specify BPN, Connector URL, digital twin IDs and so on. The target group of the testbed are IT people and these should be able to use APIs with Postman or REST API clients. |
We can make the UI an optional component, depending on how far we get with the resources and time we have. It will definitely help to explain and showcase the testbed and deliver the results. |
Overview
Explain the topic in 2 sentences
The industry core test bed shall allow companies to test and validate if their implementation fulfils all requirements for productive data provisioning (and consumption in the second stage). It shall contain a set of test cases that can be executed to e.g. check if the EDC is configured correctly, digital twins are created according to standards or if the data provided follows the right semantic models. The test cases can be based on each other and executed one after the other with increased complexity. The testbed shall tell the user where the test failed and what is wrong in a human understandable way.
The testbed shall be hosted by the association but it shall also be possible to e.g. deploy it locally.
What's the benefit?
What are the Risks/Dependencies ?
Detailed explanation
Framework Conditions:
Scope:
Open Questions/Topics:
Scope 1. - Positive Tests that everything is set up correctly.
IC Independent Scope
IC Specific Scope
Scope 2. - Negative Tests
IC Independent Scope
IC Specific Scope
Current implementation
Currently, testing is done between partners manually during the onboarding of use-cases.
Proposed improvements
The testbed should contain different microservices:
Feature Team
Contributor
Committer
User Stories
Acceptance Criteria
Test Cases
Test Case 1
Steps
Expected Result
Architectural Relevance
The following items are ensured (answer: yes) after this issue is implemented.
In the context of the standards 126 and 127, typically only one is applicable, depending on the specific use case. Please cross out one of the two standards that does not apply.
Justification: (Fill this out, if at least one of the checkboxes above cannot be ticked. Contact the Architecture Management Committee to get an approval for the justification)
Additional information
The text was updated successfully, but these errors were encountered: