kolodny

React is pretty performant when context isn't changing. We haven't done any benchmarking but I doubt there's any real world perf hit. For large applications the number of overrides tend to be under 20.

Overrides are opt-in so you can just expose any overridable value as a prop and run a isolated component test on it.

Creating an override is basically just providing a placeholder for a value to be injected via React Context. I view this as a form of dependency injection. Contrast this with how this would be done in vanilla Playwright with reading it from a query param or exposing a global to call page.evaluate on which is more along the lines of forcing test code into a component.

Note that if you needed a specific reference in an override there isn't a good way to get that via Playwright, consider this silly example:

    it('can test spies', async () => {
      const spy = browserMock.fn();
      const { page } = await render(
        app =>
          <LogoutButtonAction.Override with={() => spy}>
            {app}
          <LogoutButtonAction.Override>
      );

      await page.getByText('Log out').click();
      expect(await spy).toHaveBeenCalled();
    });

The point is that you shouldn't need to rewrite your countdown component to allow testing. Can you provide a snippet of that change and what the test would look like?

Not being toggle parts of the app is the root of the issue when creating e2e tests. For example overriding a feature flag, you could find the API call for the feature but what if it's a grpc call and part of your dev build pulls in any update, you can't easily change the binary response with confidence anymore.

The current solutions are good enough to do smoke tests, but nitty-gritty e2e tests don't scale well.

In the example above it's simple

    export const CountdownTime = createOverride(60);
    export const Countdown = () => {
      const initialTime = CountdownTime.useValue();
      const [time, setTime] = React.useState(initialTime);
      React.useEffect(() => {
        const interval = setInterval(() => {
          setTime(t => t - 1);
          if (t === 1) clearInterval(interval);
        }, 1000);

        return () => clearInterval(interval)
      }, []);

      return time > 0 ? <>Time left {time}</> : <>Done</>
    };

    it('tests faster', async () => {
      const { page } = await render(
        app => <CountdownTime.Override with={() => 5}>{app}</CountdownTime.Override>
      );
      await expect(page.getByText('Done')).not.toBeVisible();
      page.waitForTimeout(5000);
      await expect(page.getByText('Done')).toBeVisible();
    });

If I needed something like this, I'd probably also make setInterval an override as well, so I don't need to wait at all, but you get the idea.

Author here. Can you show an example of how Playwright would progress a timer on a page? For example, how would you make this component pass faster than 60 seconds?

    export const Countdown = () => {
      const [time, setTime] = React.useState(60);
      React.useEffect(() => {
        const interval = setInterval(() => {
          setTime(t => t - 1);
          if (t === 1) clearInterval(interval);
        }, 1000);

        return () => clearInterval(interval)
      }, []);

      return time > 0 ? <>Time left {time}</> : <>Done</>
    };

Short of using Playwright Component Tests, this isn't possible.

I also found an issue where the only solution was to inject sinon into the page which I wouldn't consider a great option: https://github.com/microsoft/playwright/issues/10230

Sorry about that. I just added an official LICENSE file

https://github.com/kolodny/safetest/blob/main/LICENSE

Can you clarify what you mean? Usually, e2e testers don't have a bootstrapping stage for app-level changes, only for things that can be done via the browser automation APIs.

Yes, that's correct. You get all the benefits of react-testing-library mounting and the ability to test the entire app as a unit.

Nice, Swift also handles having all the transition changes as well. I wrote a small post about how to do this: https://gist.github.com/kolodny/6fa6aa34a711d36e9de01cec4409...

Somewhat related nodejs self plug: Use nip https://github.com/kolodny/nip

    $  echo -e 'this\nis\na\nwhatever foo' | nip 'return /whatever/.test(line) && cols[1]' # foo

One of my favorite books is the "The Chess Mysteries of Sherlock Holmes" which describes a technique called retrograde analysis

https://www.amazon.com/Chess-Mysteries-Sherlock-Holmes-Recre...

There should be a link for you to delete it

http://i.imgur.com/pwHijrG.png

I wouldn't know about that. It sounds like the OP is specifically asking about people who contribute to OSS as "just a hobby"

As others have been saying, the "prolific programmers" have a passion to program that doesn't get satisfied by coding from just 9 to 5. Personally I tend to have waves of intense programming around the clock followed by a cooling down period with either part of the cycle lasting days to weeks. Sorry for the shameless self plug but you should start small and try making a "One Hour Side Project" http://kolodny.github.io/blog/blog/2015/03/03/the-one-hour-s...

That would be awesome considering you need to run _mocha with --debug-brk and it never really works that well