Today's discussion delves into testing in Deno, emphasizing its simplicity and built-in tooling. Deno offers a seamless testing experience for developers, allowing tests to be written in TypeScript without extensive setup. The platform supports BDD-style testing, provides various assertion types, advanced features like code coverage and snapshot testing, and allows for filtering tests based on keywords. Additionally, Deno facilitates component testing, dependency mocking, and migration of test suites from Jest to Deno with minimal changes.

Speaker reflects on the importance of testing, shares insights from the state of JS survey, and discusses future plans for JavaScript testing in 2025. Companies are exploring testing tools and methodologies based on surveys and personal data. Evolution of testing practices from browser to node-based environment with VTest adoption. Advancements in testing technology include VTest's role, Playwright for end-to-end testing, and comprehensive testing solutions. Progress in self-healing tests, AI integration, and tool resurgence like Storybook and MSW for API mocking. Diverse opinions on testing in 2025, with a focus on static analysis, VTest, and end-to-end testing resurgence to browser.

Introduction to Playwright as an end-to-end testing tool with easy installation and code generation. Features include visual comparisons, API testing, and best-in-class developer experience. Playwright offers AI capabilities, practical testing tools, and innovative testing strategies. Challenges in testing specialized domains are addressed, along with best practices for test dependencies and readability. Optimizing testing efficiency through parallelism, code organization, and network cache usage. The discussion also covers test performance enhancement, managing workers, optimizing dependencies, stability of test functions, and the use of Playwright sharding in CI/CD runs.

Introduction to Accessibility Testing in React applications, emphasizing early automation and challenges in scaling. Importance of instant feedback, Unity test, and entry testing for code accessibility. Utilizing end-to-end testing tools like Jest-Axi and Cypress to ensure accessibility compliance. Emphasis on manual testing alongside automated tools. Encouragement for discussions on LinkedIn to enhance accessibility knowledge.

Exploring the evolution of web forms from HTML2 to Web 3.0 and the crucial role of form validation in application development. The importance of form validation, challenges, and the need for better approaches. Introducing VEST as a flexible validation tool inspired by unit testing frameworks. Highlighting VEST's logic separation, asynchronous validation, and advanced features like caching. Discussing warning states, user guidance, and the impact of form validation on user experience and application success.

Discussion on improving release cycles and testing efficiency, transitioning to React Native, quality assurance challenges addressed through redefined responsibilities and test automation, shift-left approach for early testing and diversification of automated tests, efficient test execution with caching strategies, impact of caching on CI performance, efficiency with change recognition and caching, project-specific approaches for testing, test optimization with AI and Pyramid test structure, QA team transitioning to engineering, handling unautomated tests and test association, maintaining test stability with Git revert strategy.

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.