August 2024 Summaries

Microsoft's Playwright can be used for both end-to-end testing and API testing, enabling control over headless browsers and checking essential user flows, as well as controlling HTTP-based APIs. A demo GraphQL API is used to illustrate how Playwright can be used for API testing, with a test case that sends a POST request with a query in the request body to retrieve data from the API. The test checks if the response contains expected data and logs the entire response. To add assertions, the test uses playwright's snapshot tool to compare the response to an initial JSON file or to filter the response. Continuous monitoring of APIs can be achieved using Playwright and Checkly, a monitoring service that allows for dynamic notification settings, retries, and setup scripts, making it cheaper than browser checks.

When writing Playwright end-to-end testing code, developers can choose between JavaScript or TypeScript as their preferred language. While JavaScript was initially chosen for its simplicity, TypeScript is now recommended due to its benefits in maintaining test suites over time, such as auto-completion and warnings that help discover problems early. To make test steps more readable, especially when using Page Object Models (POMs), decorators can be used with TypeScript to automatically wrap POM methods in a nice Playwright test step showing the POM class and method. The decorator code is complex but rarely touched once set up, making it a worthwhile trade-off for the ability to set custom step names.

Adopting best practices for software deployment is crucial for maintaining quality, minimizing downtime, and meeting user expectations. A canary deployment strategy involves rolling out new code to a small subset of users before a full-scale release, allowing issues to be caught early and addressed before they impact the entire user base. Maintaining a robust rollback plan, creating focused runbooks, and making monitoring part of your CI/CD pipeline are also essential for ensuring reliable deployments. By integrating Monitoring as Code, you can define and manage monitoring configurations through version-controlled code, enabling automation, consistency, and scalability. This approach allows for end-to-end testing locally, debugging test results efficiently, and running tests directly from your CI/CD pipeline, ultimately leading to faster issue detection and a higher standard of quality throughout the deployment process.

### Choosing the right locators in Playwright is key to creating stable and maintainable tests. User-first locators reduce flakiness and encourage good development practices by emulating user actions rather than HTML structure, making them more robust and reliable. By using built-in locators like getByRole, getByText, and getByLabel, developers can ensure their tests remain stable even if class names or HTML structure change. Additionally, considering element filtering and position-based selection can help resolve issues with multiple matching elements. Best practices for locator strategies include avoiding implementation details and using data test IDs to simplify locators and improve test reliability.

The observability market has undergone significant transformations over the years, evolving from basic monitoring to more comprehensive solutions that address the needs of various engineering functions and stages of the Software Development Life Cycle (SDLC). The rise of cloud-native architectures, microservices, and distributed systems led to an explosion of data volumes, prompting vendors to consolidate all MELT data in one platform. Despite advancements in observability tooling and practices, a significant disparity remains between how these tools are leveraged across the SDLC and different engineering functions. Many vendors focus on post-deployment production problems, neglecting the needs of developers who require visibility into their code throughout the development process. This disparity is evident in the way many observability platforms are designed, often emphasizing brute-force data collection and analysis without providing actionable insights for developers. Monitoring as Code (MaC) offers a more efficient approach by integrating observability directly into the development workflow, focusing on control and efficiency, and providing benefits such as consistency, collaboration, automation, and high signal with low noise. By embedding monitoring into the codebase, engineers can define and maintain their monitoring configurations as part of their version control systems, ensuring reproducibility, collaboration, and automation. MaC has proven to be a simple and well-understood approach for developers to detect issues early in the SDLC.

Breaking programming best practices can lead to tangible benefits, particularly when it comes to performance. However, this requires understanding the rationale behind coding standards and being able to assess trade-offs and context. A key takeaway is that monitoring code running in the real world, through end-to-end testing and synthetic monitoring, is crucial for truly understanding performance. This approach allows developers to make informed decisions about when to deviate from best practices, striking a balance between maintaining clean, standardized code and achieving performance efficiencies. By doing so, they can identify opportunities to optimize their code without sacrificing readability or maintainability.

This summary highlights the challenges of end-to-end testing with Playwright, specifically test flakiness and long test execution times due to repeated login steps. The article proposes a solution using project dependencies to chain setup steps and persist session state using the `storageState` method. By leveraging these features, developers can significantly reduce test execution time and improve test efficiency.