Unit testing Azure DevOps Extensions

In my last project we faced the challenge to unit test Azure DevOps UI Extensions based on Azure DevOps React-based UI.

You will find quite some resources on how to leverage Azure DevOps to build your React apps and unit test them. But I found little information on how to do React unit tests for an Azure DevOps Extension.

Overall we faced 5 challenges from which 4 are related to Azure DevOps Extensions:

  1. Mocking return values of the Azure DevOps Extension SDK methods
  2. Trigger Azure DevOps Extension _WorkItemForm _events
  3. Mocking return values and classes of the Azure DevOps Extension API
  4. Mock the external Rest API calls and spy on the values transmitted (while using a _RestClientBase _class provided by the Extension API)
  5. Mocking and spy on logging methods (Application Insights SDK)

Let’s start with explaining the example

The example code, mocks and the unit tests are published to GitHub https://github.com/h2floh/azure-dev-ops-react-ui-unit-testing.

It contains two Work Item UI Extensions:

  1. Versioned Items Table — can link versioned items (files) from a distinct Azure Git repo branch to the work item. In order to do so it will save the state via a Rest API external to Azure DevOps Services.
  2. Multi Identity Picker — let you select multiple identities from the Azure DevOps Organization associate AAD Tenant and saves the information into a text field of the work item.

Image for post

High Level Overview of the UI components and their service interactions

The main difference between both components is that one will save the state externally the other internally to Azure DevOps Services.

Both have in common that they will use the TypeScript based Azure DevOps Extension SDK and API to communicate with Azure DevOps Service and do logging towards an Azure based Application Insights.


Ok let’s have a look at the 5 challenges and how to solve them

Disclaimer: I reordered and removed some code for the screenshots in order to highlight the important parts.

Mocking return values of the Azure DevOps Extension SDK methods

Image for post

Azure DevOps Extension SDK initialization code

The code: SDK has to be initialized and we retrieving configuration values from it.

Image for post

Azure DevOps Extension SDK initialization mock

The mock: the **SDK.init() **function needs to return a resolved promise in order to activate the lambda function in the .then() branch of the code.

The getConfiguration() function can be easily mocked by returning a JSON object with the exact structure we expect. We added all configuration values for both UI components at once.

If you need to modify specific values within a test run you can create an additional function mock which will be accessible to overwrite the return value in you test files. In this example we do that for the _RepositoryId _with a default value of ‘gitrepo’, by introducing a mocked function mockRepositoryId().

Image for post

Retrieving a field value

The code: We retrieve the Work Item Form Service with the function **getService(). **With this service we can access and modify the current work item opened in the UI. We want to retrieve the value of the field specified to hold the state of this component. This is done by the method getFieldValue().

Image for post

Mocking getService, WorkItemFormService and SearchIdentities

The mock: as you can see we need two different services returned from getService() depending on the input parameters. In case the W_orkItemFormService _is requested we just return the getFieldValue() method as a mocked function mockGetFieldValue(). This allows us to inject the return value at the unit test level. In this case we do not distinguish what field is requested. If you need to because you are accessing several fields you would need to create an implementation for **mockGetFieldValue() **which will react on different input parameters.

As an example of how to react to input parameters you can have a look at the mocked searchIdentitiesAsync() method of the IdentityService. Depending on the query value we return another identity.

Image for post

Image for post

#azure-devops #programming #react #unit-testing #typescript #devops

What is GEEK

Buddha Community

Unit testing Azure DevOps Extensions

Unit testing Azure DevOps Extensions

In my last project we faced the challenge to unit test Azure DevOps UI Extensions based on Azure DevOps React-based UI.

You will find quite some resources on how to leverage Azure DevOps to build your React apps and unit test them. But I found little information on how to do React unit tests for an Azure DevOps Extension.

Overall we faced 5 challenges from which 4 are related to Azure DevOps Extensions:

  1. Mocking return values of the Azure DevOps Extension SDK methods
  2. Trigger Azure DevOps Extension _WorkItemForm _events
  3. Mocking return values and classes of the Azure DevOps Extension API
  4. Mock the external Rest API calls and spy on the values transmitted (while using a _RestClientBase _class provided by the Extension API)
  5. Mocking and spy on logging methods (Application Insights SDK)

Let’s start with explaining the example

The example code, mocks and the unit tests are published to GitHub https://github.com/h2floh/azure-dev-ops-react-ui-unit-testing.

It contains two Work Item UI Extensions:

  1. Versioned Items Table — can link versioned items (files) from a distinct Azure Git repo branch to the work item. In order to do so it will save the state via a Rest API external to Azure DevOps Services.
  2. Multi Identity Picker — let you select multiple identities from the Azure DevOps Organization associate AAD Tenant and saves the information into a text field of the work item.

Image for post

High Level Overview of the UI components and their service interactions

The main difference between both components is that one will save the state externally the other internally to Azure DevOps Services.

Both have in common that they will use the TypeScript based Azure DevOps Extension SDK and API to communicate with Azure DevOps Service and do logging towards an Azure based Application Insights.


Ok let’s have a look at the 5 challenges and how to solve them

Disclaimer: I reordered and removed some code for the screenshots in order to highlight the important parts.

Mocking return values of the Azure DevOps Extension SDK methods

Image for post

Azure DevOps Extension SDK initialization code

The code: SDK has to be initialized and we retrieving configuration values from it.

Image for post

Azure DevOps Extension SDK initialization mock

The mock: the **SDK.init() **function needs to return a resolved promise in order to activate the lambda function in the .then() branch of the code.

The getConfiguration() function can be easily mocked by returning a JSON object with the exact structure we expect. We added all configuration values for both UI components at once.

If you need to modify specific values within a test run you can create an additional function mock which will be accessible to overwrite the return value in you test files. In this example we do that for the _RepositoryId _with a default value of ‘gitrepo’, by introducing a mocked function mockRepositoryId().

Image for post

Retrieving a field value

The code: We retrieve the Work Item Form Service with the function **getService(). **With this service we can access and modify the current work item opened in the UI. We want to retrieve the value of the field specified to hold the state of this component. This is done by the method getFieldValue().

Image for post

Mocking getService, WorkItemFormService and SearchIdentities

The mock: as you can see we need two different services returned from getService() depending on the input parameters. In case the W_orkItemFormService _is requested we just return the getFieldValue() method as a mocked function mockGetFieldValue(). This allows us to inject the return value at the unit test level. In this case we do not distinguish what field is requested. If you need to because you are accessing several fields you would need to create an implementation for **mockGetFieldValue() **which will react on different input parameters.

As an example of how to react to input parameters you can have a look at the mocked searchIdentitiesAsync() method of the IdentityService. Depending on the query value we return another identity.

Image for post

Image for post

#azure-devops #programming #react #unit-testing #typescript #devops

How to Extend your DevOps Strategy For Success in the Cloud?

DevOps and Cloud computing are joined at the hip, now that fact is well appreciated by the organizations that engaged in SaaS cloud and developed applications in the Cloud. During the COVID crisis period, most of the organizations have started using cloud computing services and implementing a cloud-first strategy to establish their remote operations. Similarly, the extended DevOps strategy will make the development process more agile with automated test cases.

According to the survey in EMEA, IT decision-makers have observed a 129%* improvement in the overall software development process when performing DevOps on the Cloud. This success result was just 81% when practicing only DevOps and 67%* when leveraging Cloud without DevOps. Not only that, but the practice has also made the software predictability better, improve the customer experience as well as speed up software delivery 2.6* times faster.

3 Core Principle to fit DevOps Strategy

If you consider implementing DevOps in concert with the Cloud, then the

below core principle will guide you to utilize the strategy.

  • It is indispensable to follow a continuous process, including all stages from Dev to deploy with the help of auto-provisioning resources of the target platform.
  • The team always keeps an eye on major and minor application changes that can typically appear within a few hours of development to operation. However, the support of unlimited resource provisioning is needed at the stage of deployment.
  • Cloud or hybrid configuration can associate this process, but you must confirm that configuration should support multiple cloud brands like Microsoft, AWS, Google, any public and private cloud models.

Guide to Remold Business with DevOps and Cloud

Companies are now re-inventing themselves to become better at sensing the next big thing their customers need and finding ways with the Cloud based DevOps to get ahead of the competition.

#devops #devops-principles #azure-devops #devops-transformation #good-company #devops-tools #devops-top-story #devops-infrastructure

Software Testing 101: Regression Tests, Unit Tests, Integration Tests

Automation and segregation can help you build better software
If you write automated tests and deliver them to the customer, he can make sure the software is working properly. And, at the end of the day, he paid for it.

Ok. We can segregate or separate the tests according to some criteria. For example, “white box” tests are used to measure the internal quality of the software, in addition to the expected results. They are very useful to know the percentage of lines of code executed, the cyclomatic complexity and several other software metrics. Unit tests are white box tests.

#testing #software testing #regression tests #unit tests #integration tests

Nabunya  Jane

Nabunya Jane

1624939448

A side-by-side comparison of Azure DevOps and GitHub

Collaboration is a crucial element in software development; having the right collaboration tools can make a difference and boost the entire team’s productivity. Microsoft introduced its Application Lifecycle Management product with Team Foundation Server (aka TFS) on March 16th, 2006. This software had to be installed on a server within your network and had a user-based license. To reduce the complexity of setting up and maintaining the server, Microsoft released Visual Studio Online–an Azure-based, server-hosted version of TFS. Microsoft manages and administers the servers as well as taking care of backups. To clarify its commitment to agile and DevOps, Microsoft rebranded Visual Studio Online in 2015 as Visual Studio Team Services and later as Azure DevOps in 2018.

Since its beginning, this platform has changed significantly. For example, it introduced a customizable, task-based build service, release gates, and much more. Many organizations across the world made a significant investment to run their businesses on Azure DevOps. For this reason, after Microsoft announced the acquisition of GitHub in mid-2018, GitHub announced its automated workflow system, which is much like Azure Pipelines. It’s called GitHub Actions. Due to the switch, some companies became afraid of having to migrate their practices again. In the past few months, I have gotten several questions about whether it is still worth starting new projects on Azure DevOps, especially after the release of features like GitHub Advanced Security and GitHub Codespaces (similar to Visual Studio Codespaces). In this article, I’ll clarify the differences between these two platforms, and I’ll give you some advice on how you should be using them to your advantage.

Data Residency

To meet the needs of companies that want to keep their data within their network, both GitHub and Azure DevOps provide a server version of their platform. GitHub version is called GitHub Enterprise Server, and the Azure DevOps version is called Azure DevOps Server. Both versions require the client to install and maintain both software and machine.

On the other hand, there is a critical difference between their cloud-hosted version. While Azure DevOps Service allows you to choose the Azure region, which is closes to your organization’s location, to decrease the eventuality of networking latency during the creation of your organization (collection of projects). GitHub doesn’t provide this feature.

Project management and bug tracking

GitHub

At the core of GitHub project management, we can find the issues. This task can be used to track any work item, from feature to bugs, and can be sorted into a Kanban-style board for easy consultation. The issue’s description also supports markdown syntax. Adding a specific keyword #issue-number (ex: #3) can associate the issue with another one. Each issue can be assigned to multiple developers, be linked to pull requests, and have various labels assigned to it. One can link a pull request to an issue to show that a fix is in progress and automatically close the issue when someone merges the pull request.

GitHub Kanban board

  • Lastly, multiple issues can be grouped into milestones that will give immediate feedback about the completion percentage. Milestones can also include a due date.

#azure-devops #microsoft #azure #github #azure devops #azure devops and github

Tamia  Walter

Tamia Walter

1596754901

Testing Microservices Applications

The shift towards microservices and modular applications makes testing more important and more challenging at the same time. You have to make sure that the microservices running in containers perform well and as intended, but you can no longer rely on conventional testing strategies to get the job done.

This is where new testing approaches are needed. Testing your microservices applications require the right approach, a suitable set of tools, and immense attention to details. This article will guide you through the process of testing your microservices and talk about the challenges you will have to overcome along the way. Let’s get started, shall we?

A Brave New World

Traditionally, testing a monolith application meant configuring a test environment and setting up all of the application components in a way that matched the production environment. It took time to set up the testing environment, and there were a lot of complexities around the process.

Testing also requires the application to run in full. It is not possible to test monolith apps on a per-component basis, mainly because there is usually a base code that ties everything together, and the app is designed to run as a complete app to work properly.

Microservices running in containers offer one particular advantage: universal compatibility. You don’t have to match the testing environment with the deployment architecture exactly, and you can get away with testing individual components rather than the full app in some situations.

Of course, you will have to embrace the new cloud-native approach across the pipeline. Rather than creating critical dependencies between microservices, you need to treat each one as a semi-independent module.

The only monolith or centralized portion of the application is the database, but this too is an easy challenge to overcome. As long as you have a persistent database running on your test environment, you can perform tests at any time.

Keep in mind that there are additional things to focus on when testing microservices.

  • Microservices rely on network communications to talk to each other, so network reliability and requirements must be part of the testing.
  • Automation and infrastructure elements are now added as codes, and you have to make sure that they also run properly when microservices are pushed through the pipeline
  • While containerization is universal, you still have to pay attention to specific dependencies and create a testing strategy that allows for those dependencies to be included

Test containers are the method of choice for many developers. Unlike monolith apps, which lets you use stubs and mocks for testing, microservices need to be tested in test containers. Many CI/CD pipelines actually integrate production microservices as part of the testing process.

Contract Testing as an Approach

As mentioned before, there are many ways to test microservices effectively, but the one approach that developers now use reliably is contract testing. Loosely coupled microservices can be tested in an effective and efficient way using contract testing, mainly because this testing approach focuses on contracts; in other words, it focuses on how components or microservices communicate with each other.

Syntax and semantics construct how components communicate with each other. By defining syntax and semantics in a standardized way and testing microservices based on their ability to generate the right message formats and meet behavioral expectations, you can rest assured knowing that the microservices will behave as intended when deployed.

Ways to Test Microservices

It is easy to fall into the trap of making testing microservices complicated, but there are ways to avoid this problem. Testing microservices doesn’t have to be complicated at all when you have the right strategy in place.

There are several ways to test microservices too, including:

  • Unit testing: Which allows developers to test microservices in a granular way. It doesn’t limit testing to individual microservices, but rather allows developers to take a more granular approach such as testing individual features or runtimes.
  • Integration testing: Which handles the testing of microservices in an interactive way. Microservices still need to work with each other when they are deployed, and integration testing is a key process in making sure that they do.
  • End-to-end testing: Which⁠—as the name suggests⁠—tests microservices as a complete app. This type of testing enables the testing of features, UI, communications, and other components that construct the app.

What’s important to note is the fact that these testing approaches allow for asynchronous testing. After all, asynchronous development is what makes developing microservices very appealing in the first place. By allowing for asynchronous testing, you can also make sure that components or microservices can be updated independently to one another.

#blog #microservices #testing #caylent #contract testing #end-to-end testing #hoverfly #integration testing #microservices #microservices architecture #pact #testing #unit testing #vagrant #vcr