Hello, I'm grateful that you chose to watch my talk. Thank you. Last week, I had to run some unit tests while I was coding. Business performance can be awesome. It has very interesting and outstanding features. These test sets are overly complex. It's easy to find yourself troubleshooting for hours. VTest has almost 200 configuration options. By explaining how things work, we can answer questions about using complex third-party runners versus the built-in node.js runner. Understanding better helps avoid pitfalls, troubleshoot faster, and identify opportunities for configuring things better. The CLI layer does validation and hands over to the VTest class. It searches for test files, runs them efficiently using a pool of workers, and ensures isolation to prevent issues with dirty state. VTest uses the piscina library to facilitate work with multiple workers and improve performance. The workers prepare by setting the right globals, initializing snapshots, deciding the test runner file, and starting coverage collection. Each worker executes all the tests in a file and sends an RPC message when done. The decision to reuse or create a fresh worker is determined by the isolate configuration option. Consider spreading tests among more files to fully utilize the machine. Choose between process, thread, or VM as the worker type. In terms of isolation, you can choose between using a process, a thread, or a VM. Process is the heaviest in terms of performance cost, while thread is lighter. VM performance depends on known slower aspects like accessing globals. Process is the classic choice for stability, but thread has limitations and known issues. VM has reporting issues with memory leaks. Benchmark results showed that using multiple processes was 50% better for real-world applications, but for unit tests, one process was ten times faster. Thread was slightly faster than process, and VM was slower. The price of isolation with process worker types was approximately three minutes. Without isolation, the tests lasted only two minutes, much faster, but with a few failures. Threads showed similar results with a few failures. The risk of dealing with testing issues increases without isolation. By default, tests run sequentially inside workers, but you can configure them to run in parallel using the 'concurrent' keyword. However, tests still run sequentially despite specifying 'concurrent'. Concurrency in VTest is based on promises and requires asynchronous work. Unit tests run sequentially and concurrency has no isolation. Mocking in one test affects other tests running simultaneously. In choosing worker configurations, it depends on the context. In-file concurrency is best avoided, and the process worker type is recommended as the default. Isolation is crucial in integration tests but not mandatory in unit tests. Inside the worker, a TypeScript file is handled, and failures can occur when mocking functions. Mocking doesn't work in the worker. The worker handles TypeScript files and transpiles them using Vite server. Vite server replaces imports and hoists the mocking. Vite introduces a new module loader in the runtime. Vite hoisted the mock to the first line in the transform code to make it before the import. Additionally, Vite changes mocks to dynamic imports, ensuring that mocking works. Vite intercepts function calls on the file import level, but cannot intercept calls between functions in the same file. Moving function two to a different file or using an object export can solve this issue. Function one calls function two on the same object context. Use Spy to replace functions inside the object. Vite offers a range of plugins for different functionalities. You can fix import issues by customizing Vite's runtime. The Vite server handles dependency resolution and transformation. Consider using the built-in test runner or mockup for small-scale testing. Gain a better testing experience with Vite's customized runtime.

At Evinced, the mission is to make the web more accessible for everyone. Accessibility issues are common despite intentions. Today's Talk focuses on coding in an accessible way using TDD to catch defects early. Unit tests can be written to ensure accessibility requirements are met. Testing Library provides utilities for testing accessibility. The ATDD approach allows continuous creation of tests for compliance. Unit testing is valuable for complex components. Advanced has developed an SDK called the Unit Tester for automating accessibility tests.

Today's talk is called Beyond Testing Library, Testing React Libraries and Library-like Code. The speaker, Lenz Liebertronik, discusses the special requirements for testing libraries, including minimizing re-renders, avoiding tearing, and rendering components granularly. They highlight scenarios where React Testing Library falls short and introduce the Testing Library React render stream as a solution. The speaker demonstrates how to test hooks, multiple hooks, and assert re-renders using different techniques. They caution about potential issues with React upgrades, test-only components, ACT batching, and Suspense boundaries. The speaker shares real-world usage of the render stream library and discusses the limitations of correlating renders with DOM commits. They emphasize the importance of testing libraries and gradually optimizing code. They also mention the benefits of using the testing library and conclude with gratitude and a Dutch lesson.

My goal with this talk was to answer the question of why we have another test runner. The talk breaks down the history of web testing into three chunks: the click-through era, browser war one, and browser war two. It discusses the motivations behind browser test runners and node test runners, highlighting Karma as the first node-based runner that gained popularity. The rise of node-based test runners like Ava, Tape, Mocha, and Jest is attributed to their stability and ease of use compared to Karma. Jest faced challenges with module loading and transpiling, but its non-opinionated abstraction made it a suitable choice. The shift towards environment-aware runners like VTest allows for safer testing and aligns with the need for transpilation across different environments. Lastly, the talk touches on the future of test tooling and the implications of AI on testing.

End-to-end testing is important for catching hard-to-find bugs, but it can be complex and time-consuming. The speaker shares their journey at YOLO apps and how they addressed these issues using Maestro, a newer testing tool. Maestro allows interaction with all aspects of the app and offers a web interface for building tests. It also provides features like auto retry and test videos for troubleshooting. The speaker also discusses automating CI/CD using Expo and EAS, which simplified the app build and distribution process. They demonstrate how EAS and MySQL Cloud can be used for reporting and investigation. The power of end-to-end testing is showcased, with a fast CI/CD time and free tests and EAS updates. Maestro has some limitations, but it offers easy test writing and 100 free tests per month, with additional tests available at a cost.

Hello, everyone. Today we are going to explore AI-powered end-to-end testing. Unlike unit tests, UI testing has a huge layer of obstructions between the source code and the rendered UI. The source code includes HTML, CSS, and TypeScript, which are transpiled into JavaScript and bundled with tools like Webpack. AI can generate tests effectively for standard websites or blogs, but it may struggle with niche applications behind strict authorization or on-premise tools. AI-powered end-to-end testing for complex scenarios requires our guidance. We use meaningful data test IDs and follow the page objects model pattern. Additionally, we rely on useful tools like the end-to-end test helper in-browser extension and the continue IDE extension. Now, let's proceed to the demo, where we will create tests for the Pokemon application, including the ability to filter by name or type. We will navigate to the Pokemon details page and use our extension to manage settings and prompts. Additionally, we will create the details page object together and generate the test file. The Pokemon details page has 105 elements. We can view the elements for debugging purposes, including page object name, Pokemon details page, and system message. We will copy the page object and save it to a file. We need to make it exportable. Then, we will use the extension to create an end-to-end test and pass the context. I will use all the open files, including the page objects and the test case itself. I will send them to EI along with the predefined prompt. There is a system message and additional information we need to be aware of. The test runs successfully, and that concludes this part.

Visual Regression Tests are like unit or integration tests but focus on the visual part, allowing developers and QA personnel to identify and address any changes. Challenges in detecting UI changes include elements that are not visible to the human eye and misalignment of elements. Use cases for Visual Regression Tests include testing design system components, responsive designs, and browser renderings. Building a Visual Regression Test Tool involves handling animations, network requests, and flakiness. Docker is the best solution for resolving visual regression issues, and finding the baseline for comparison can be challenging but is handled by the testing tool.

Hi, everyone. My name is Debbie O'Brien, Principal Technical PM at Microsoft. I'm focusing on Playwright, a reliable end-to-end testing tool for modern web apps. It works on any browser and platform, has powerful tooling, and tests run fast. Advanced techniques include UI mode, HTML reports, and trace viewer. Use annotations in Playwright to enhance reporting and test organization. Mocking API responses and external links is possible with Playwright. You can also test date and time by setting a fixed fake time. Playwright offers CLI test options and has a vibrant community. Join the Playwright Discord server and follow the important docs and YouTube channel for more information.