An example: a legal requirement<\/em> is specified and linked to a technical requirement<\/em> which specifies how to fulfill the legal constraints. The technical requirement<\/em> could specify valid test result ranges of a computation. Since this all needs to be recorded, the computation (e.g. a program code file) needs to be linked to the technical requirement<\/em> too. If the result of that program complies to the technical requirements<\/em> the link is called valid or consistent.<\/p><\/blockquote>\n
Creating the links and checking the validity is a labor-intensive manual task. It is also not easy to track manually if a validation must be redone because the program code was changed. Therefore, the overall goal is to automate or at least assist manual validation as much as possible.<\/p>\n
Azure Boards provides the possibility to highly customize software development processes and already includes linking features between any type of so-called Work Items (in this case a legal or technical requirement, epic, user stories etc.). Therefore, it was chosen as the foundation for the implementation.<\/p>\n
In a first phase we helped develop the customization and logic to invalidate links to code artifacts if they were changed in a git-based code repository. This helps to identify which validations must be redone.<\/p>\n
Errors in the automation tools could break the traceability aspect of A-SPICE and hence ultimately could result in legal consequences for our customer (e.g., when a required root cause examination could not be answered in court). Therefore we needed to achieve complete unit test code coverage for all parts of the automation tools. This will help identifying functional errors in early development, especially as these tools grow in complexity in the next phases.<\/p>\n
Part of these automation tools is an Azure Boards Work Item UI extension based on the Typescript React Framework for Azure DevOps<\/a>. In this post we will only focus on this Work Item UI extension and how to achieve unit testing with complete code coverage for it.<\/p>\n
<\/p>\n
Requirements and Challenges<\/h2>\n
This post will demonstrate how we achieved the non-functional requirement for the development and what we did to achieve the functional requirement.<\/p>\n
Functional Requirements:<\/h4>\n
\n
- Assist in finding linked code artifacts (stored in git repository) which need to be re-validated (VersionedItems)<\/li>\n
- Any requirement can have multiple owners<\/li>\n<\/ul>\n
Non-Functional Requirement:<\/h4>\n
\n
- Achieve complete code coverage for all components of the developed automation tools<\/li>\n<\/ul>\n
Challenges to achieve the Functional Requirement:<\/h4>\n
\n
- Azure Boards does not support git repository Versioned-Item links, therefore we had to develop a custom UI control<\/li>\n
- Azure Boards does not support multiple owners of a Work Item, therefore we had to develop a custom UI control<\/li>\n<\/ul>\n
Both controls are packed together into one Azure DevOps Extension.<\/p>\n
Challenges to achieve the Non-Functional Requirements:<\/h4>\n
\n
- Creating unit tests for Azure DevOps React\/Typescript based UI components with complete code coverage<\/li>\n<\/ul>\n
To unit test the components we need to cut off all external service dependencies. If an SDK method is used which leads to an API call there is a need to short cut the request and instead return a local dummy value for testing. To achieve the complete code coverage for the UI components there were following six sub-challenges to resolve these external service dependencies:<\/p>\n
\n
- Mocking return values of Azure DevOps Extension SDK<\/a>\u00a0methods\n
\n
- Azure DevOps environment related input parameters like current User, input parameter for the controls. How can we mock these parameters?<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
\n
- Mocking Azure DevOps Extension SDK<\/a> service clients\n
\n
- The SDK provides accessors to service clients. How can we mock these clients and their method results?<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
\n
- Triggering Azure DevOps Extension WorkItemFormUI <\/em>event callbacks\n
\n
- The controls implement callbacks (event handlers) to be informed about changes to the WorkItem (e.g. onSave, onDelete, onRefresh). These are triggered when the user is interacting with the WorkItemFormUI<\/em>. How can we trigger them in the unit test?<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
\n
- Mocking return values and service clients of the Azure DevOps Extension API<\/a>\n
\n
- A service client for accessing the Git repos is used, how can we mock this client, and its methods return values?<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
\n
- Mock the external REST API calls and spy on the values transmitted\n
\n
- Additional services were developed to achieve the functional requirement. How can we mock the generic REST Client we are using?<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
\n
- Mocking and spy on logging methods (Application Insights SDK)\n
\n
- How can we verify that logs are correctly processed by the logging system?<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
<\/p>\n
Solution<\/h2>\n
Functional Requirements<\/h3>\n
We will not go into implementation details for the functional requirements in this blog post. The example Azure DevOps Extension (provided on GitHub<\/a>) contains two Work Item UI controls:<\/p>\n
\n
- Versioned Items Table<\/a> \u2014 can link versioned items (code artifacts) from a distinct Azure Git repo branch to the work item. To do so it will save the state via a REST API external to Azure DevOps Services.<\/li>\n
- Multi Identity Picker\u00a0<\/a>\u2014 selects multiple identities from the Azure DevOps Organization associate AAD Tenant and saves the information into a text field of the work item.\n
![\"Conceptual](\"https:\/\/devblogs.microsoft.com\/cse\/wp-content\/uploads\/sites\/55\/2021\/03\/image-for-post.png\")
<\/a>