While i and my testers gained advanced knowledge of Salesforce Automated testing setting up educational material I also wanted to dive deeper into the Microsoft dynamics and learning how to setup an automated test

Please feel free to check out the microsoft page but I enhanced it slightly in my own repo to support relative paths, and other small stuff.

https://learn.microsoft.com/en-us/dynamics365/guidance/resources/test-automation-setup

Why Microsoft Dynamics with playwright

Using Playwright with Dynamics 365 for test automation is advantageous for several key reasons, reflecting broader trends in modern web development and testing practices:

The document linked from Microsoft Dynamics 365 Guidance focuses on setting up test automation, specifically mentioning the use of Playwright for automating web tests. Using Playwright with Dynamics 365 for test automation is advantageous for several key reasons, reflecting broader trends in modern web development and testing practices:

Why Playwright with microsoft dynamics

1. Cross-Browser Testing

Compatibility: Playwright supports testing across multiple browsers (Chromium, Firefox, and WebKit), which is crucial for ensuring that Dynamics 365 applications work seamlessly across different environments that users may access the applications from.

2. Automated UI Testing

Rich UI Interactions: Dynamics 365 applications often feature complex user interfaces. Playwright provides a rich set of APIs for simulating user actions (clicks, typing, navigation, etc.) in a way that closely mimics real user interactions.

3. Consistency and Reliability

Stable Tests: Playwright’s auto-wait features and the ability to work with dynamic content efficiently help in creating more stable and reliable tests by reducing flakiness associated with loading states and asynchronous operations.

4. Authentication and State Management

Efficiency: Dynamics 365 tests often require setup steps like authentication. Playwright’s ability to save and reuse browser states (storage state) makes it possible to efficiently manage sessions and states between tests, significantly speeding up the test suite.

5. Headless and Headed Testing

CI/CD Integration: Playwright can run tests in headless mode for faster execution in CI/CD pipelines, as well as in headed mode for debugging. This flexibility is important for developing and maintaining Dynamics 365 applications across different stages of the development lifecycle.

For testautomation Microsoft Dynamics they are promoting playwright of course and I totally get that as this is a microsoft product as well. Diving deeper into playwright I get to know some features which are working better then in Selenium which I want to highlight in this blog (storage state)

What I really love is the state storagefeature within playwright which allows you to capture and reuse browser storage. This is including cookies, local storage, and session storage) across test runs. This feature in Playwright is particularly useful for bypassing login screens and setting up tests quickly by preserving session state.

Example

sync function globalSetup(config) {
  // Ensure the storage state directory exists
  if (!fs.existsSync(storageStateDirectory)) {
    fs.mkdirSync(storageStateDirectory, { recursive: true });
  }

  const browser = await chromium.launch({ headless: false });
  const page = await browser.newPage();
  console.log(username);
  await login(page, orgurl, username, password);

  // Save the storage state to the relative path
  await page.context().storageState({
    path: authFile,
  });

  await browser.close();
}

export default globalSetup;

For what purpose you can use this

1. Session Persistence Across Tests

Authentication: The most common use case for saving a storage state involves user authentication. Logging in to a web application can be time-consuming and repetitive if you need to do it for every single test case. By saving the storage state after logging in (which includes cookies, local storage, and session storage), you can bypass the login process in subsequent tests, significantly speeding up the test suite.

2. Consistency

Environment Setup: The storage state ensures that each test starts with the same predefined environment setup. This includes not just authentication tokens but also any user preferences, settings, or stateful interactions that are stored in the browser. Starting from a known state helps in reducing test flakiness and ensuring consistency across test runs.

3. Testing Efficiency

Speed: Directly loading a saved storage state is much faster than navigating through a series of UI interactions to reach a certain state manually. This efficiency is particularly beneficial in CI/CD pipelines where time is a critical factor.

Resource Utilization: Reducing the number of interactions with the server by avoiding repetitive tasks like login also decreases the load on the testing infrastructure, leading to more resource-efficient test execution.

4. Real User Experience Simulation

Stateful Interaction: Modern web applications often rely on client-side storage for managing various aspects of the user experience. By capturing and reusing a specific storage state, tests can more accurately simulate real-world user interactions and scenarios, ensuring that the application behaves as expected not just in a “clean” state but also in more complex, stateful scenarios.

5. Security and Compliance

Sensitive Information: Handling login credentials and other sensitive information directly in test scripts poses security risks. By using a storage state, sensitive details can be abstracted away. The storage state can be generated once and then securely stored and reused, minimizing the exposure of credentials.

6. Flexibility in Test Design

Different States for Different Tests: You can create and use different storage states for different testing scenarios. For example, one state might represent a newly registered user, while another might represent a user with a populated shopping cart. This flexibility allows for more comprehensive and targeted testing strategies.

What about cypres and selenium faced state storage

To highlight this is a fantastic feature is that selenium faced applications like webdriverio and or katalon it is also possible to set up state storage, but not out of the box and this is more cumbersome. This is also the case for Cypress. But nonetheless I still try to be objective, and although i think playwright has its right in the ecosystem and is really a fantastic product, my personal preference remains with the wdio project , which I think is super awesome, especially with the future bidi support and all other features which are totally of topic for this blog :-)

What about the playwright script itself

The Playwright script automates the process of creating a new case in the Customer Service Hub application, which is part of Microsoft Dynamics 365, a suite of enterprise resource planning (ERP) and customer relationship management (CRM) software applications. The script does the following steps:

Environment Setup:

It starts by importing necessary dependencies, including Playwright’s testing functions, environment variables via dotenv for sensitive or environment-specific information (like application IDs), and a set of predefined selectors and utilities from local files. These selectors and utilities are presumably tailored to navigate and interact with the UI of the Customer Service Hub effectively. Remember do not publish .env , should be always in .gitignore (Best practice)

Test Definition:

It defines a test titled “Create Case” using Playwright’s test function. This test encapsulates the steps needed to create a new case within the Customer Service Hub.

Navigating to the Customer Service Hub App:

Retrieves the application ID for the Customer Service Hub from environment variables.

Uses a utility function navigateToApps to open the Customer Service Hub application within a browser page controlled by Playwright. This step likely involves navigating to the appropriate URL and waiting for the application to load.

Opening the Cases Section:

Locates and clicks on the menu option to open the “Cases” section within the application. This is done using a combination of custom selectors (defined in commonselectors.json) and a utility function stringFormat to dynamically construct the selector based on the application’s structure.

Creating a New Case:

• Clicks on a button to create a new case.
• Fills in the case title with a dynamically generated string to ensure uniqueness (“TEST CASE AUTOMATION - " followed by a random number).
• Searches for a customer by name (“Learnautomatedtesting”) in a lookup field and selects it. This involves interacting with UI components identified by their roles (button and treeitem) and specific names.

Filling in Case Details:

• Enters a description for the case, detailing an issue with turning on a coffee machine.

Saving the Case:

• Clicks on the save button to submit the new case.
• Verification:
• Waits until the application is idle (presumably to ensure the save operation is complete and the case is fully created).
• Retrieves and logs the case number of the newly created case, verifying that the case creation process has completed successfully.
• Logging:

The case number of the newly created case is printed to the console, serving as a confirmation of the action taken by the script.

The initial repo can be find

here https://github.com/learn-automated-testing/dynamics_playwright/ an education regarding this I will publish on my website in the coming months

Video example can be found here