Moshe Kolodny newly Introduced SafeTest, has been described as a new approach to front-end web testing. SafeTest orchestrates a test engine, browser automation library, UI framework, and dependency injection capabilities to mitigate weaknesses in traditional UI testing methods. SafeTest is currently used in Netflix.
Kolodny explained in the release note that the two main approaches to UI testing, i.e. unit testing and end-to-end testing, both offer trade-offs.
As user interfaces become more commonly written using a component-based framework (e.g., React, Vue, Angular), UI unit testing often turns into component testing. Components associated with a framework require that the framework provide custom testing capabilities (for example, React's act way in react-dom/test-utils, Angular TestBed API). As components became larger and more complex, component dependencies ballooned (for example, the UI framework, component children and props, the DOM, the grid, various side-effect functions, configuration settings, and more). Unit testing (i.e. testing units in isolation from their dependencies) thus turns out to be an increasingly daunting task. This unit testing often forces developers to refer to internal implementation details in their tests, leading to unexplained test failures as component implementation changes.
As a result, front-end developers in recent years have moved away from surface rendering (e.g. React enzymes library) to the full DOM width (for example, a Dom test library collection). Since components are responsible for a smaller portion of the specifications of the full application, the idea is to test those specifications through Use DOM tools as a real user will (for example, mock user actions on the DOM).
Although there are high-quality mockups of the DOM (e.g. JS Dom), for use primarily in non-browser runtimes such as Node.js, but they still fail to implement the full list of web standards, and thus do not fully replicate browser behavior in all cases.
Kolodny to explain:
Although it is easy to write test setup, it is more difficult to write the events needed to cause things to happen on the page. For example, a fancy show
<Dropdown />It's not as simple as just callingfireEvent.click('select')Because js-dom doesn't exactly match the real browser, so you'll end up needing to hover your mouse over the label and then clickselect. In the same vein, knowing how to enter text on a smart device<Input />You have a similar fight. Figuring out the exact spell to achieve this is difficult and fragile. Debugging errors because something has stopped working is also difficult since you can't open the browser and see what's going on.
This led to components being tested without mocking the browser, and instead using header or headless versions of browsers (e.g. Playwright for Microsoft, Google puppeteer).
At the extreme, removing all dummies leads to the second testing method mentioned by Kodolny: end-to-end testing. Kodolny warned against the associated quid pro quo:
E2E tests like Cypress and Playwright are great for testing the actual application. They use a real browser and work against the actual application. They are able to test things like z index issues etc.
However, they lack the ability to test components separately, which is why some teams will end up having a Storybook-adjacent version to point their E2E testing to.
Another problem is that it is difficult to prepare different test fixtures. For example, if you want to test whether an admin user has an edit button on the page while a regular user does not, you will find some ways to bypass the authentication service to return different results.
Likewise, component testing is not possible when we have external service dependencies like OAuth because Cypress and Playwright component testing is not run against a physical instance of the application, so any authentication gateway can make exposing components impossible.
SafeTest presents itself as a third method that combines the best of the previous two methods (unit testing and end-to-end testing). SafeTest allows leveraging a real browser (with screenshots, video recording and playback, and viewer tracking) while still allowing mocking of non-browser dependencies.
SafeTest may make use of other libraries to mock or stop external dependencies such as network or web services. The playwright allows for example Network layer suppression. For internal dependencies (e.g., static functions, values, and API responses), SafeTest provides a mock/spy API and The dependency injection mechanism is aptly named Transgression.
One user on Hacker News He emphasized that SafeTest can provide a dependency injection mechanism suitable for React:
Should it be a general framework focused on DI [Dependency Injection] To answer? This can make overrides more organic and have more benefits than just testing.
Another hacker news user He saw that the dependency injection needs could be alleviated By stating implicit dependencies in the form of parameters:
I'm afraid the answer to this doesn't lie in the tools. It lies in software design. If something needs to be controlled, it needs to be controlled. Usually this means payment. In a React component, this means props. It can be an optional component, but once there, this component can be controlled. Once a component can be controlled with a push, the page that displays the component can also be controlled with a push. How to push to the page? Query string parameters are the most straightforward.
The type of short stories is possible [that].
Another user agreed that SafeTest addresses real pain points, albeit in an unfamiliar way:
I think the solutions described are really interesting and valuable! There are some idiosyncrasies about the unit testing UI that are difficult to overcome. The issues with e2e tests in the context of testing individual UI parts are also quite valid.
One thing that initially rubbed me the wrong way at least was how the overrides worked. I also understand why this is a solution for how to inject some data, but I don't like the idea of writing test-specific code into a component just to enable tests with this tool. However, I've done similar things in the past when I ran out of options and this seems so clean, I'm just wondering if there's another way.
Safe testing It is open source software under the MIT license. Developers can review He issued a memorandum For more technical details and code samples.
