Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SafeTest: A novel approach to front end testing

netflixtechblog.com

Post reply on HN
Print view View original

31–35 of 35 posts

Re: SafeTest: A novel approach to front end testing

#31

Post by nosefurhairdo »

technion wrote: post #27
somewhereoutth wrote: post #26

I've said it before, and I'll say it again: Interfaces used by humans must be tested by humans. These can either be your staff, or your customers. Yes that does mean wading through each interaction pathway every time you make a release, there really is no substitute.

I think netflix is at a scale where you can question what I'm saying below, but every frontend test suit I've seen is so full of mocks you basically only test your own test suite. And then common front end bugs like "renders off the screen" or "doesnt work in safari" aren't caught anyway. I hugely support tests and I write a lot more of them than most people. I just don't think it usually works on the frontend.

I work on fairly complex, dashboard-y, web app UI used by many fortune 100 companies. I can count on one hand the number of times the huge test suite I inherited has prevented bugs entering production. I've spent at least 40 hours debugging false positives and config issues, and about half of our deployment time is spent running these tests.

From what I can tell, there are two types of tests that are worthwhile in UI: unit tests on functions (not UI elements), and basic integration tests. I believe it's possible to write valuable tests that don't fit into this framework, but from what I can tell every other UI engineer feels compelled to write tests that just regurgitate component implementation details.

Re: SafeTest: A novel approach to front end testing

#32

Post by phantomathkg »

mdaniel wrote: post #10
joks wrote: post #9

Earlier quoted context omitted.

Is hitting the (x) on the banner that difficult?

Is having nagware for another company a good look for an engineering blog? > How we GraphQL all the things, after this brief message from our ... sponsor?

Not OP, but apparently many companies still hosted their engineering blog on medium. So the answer to your question could be, yes and no, it depends.

Pinterest: https://medium.com/pinterest-engineering Workable: https://engineering.workable.com/ Skyscanner: https://medium.com/@SkyscannerEng Agoda: https://medium.com/@agoda.eng

Re: SafeTest: A novel approach to front end testing

#33

Post by nsfmc »

kolodny wrote: post #16
drewcoo wrote: post #14

Earlier quoted context omitted.

If you want to do it with the whole page and talk only to the local code, then yes, I'd recommend Sinon. I think that's a much simpler solution than . . . creating an all new NIH framework! I'd also recommend refactoring to a more mock-friendly way to do that countdown if you don't want to cover up all the internal logic. If the timeout interval is loaded remotely from some API (and it probably is if you have reasona…

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…

i think the library's approach to DI is pretty neat (and meets a team where they are which is worth a lot), but i think you're running into an issue where people are saying that instead of working around the realities of your codebase, team and testing needs, you should have done something like this.

  const useCountdownValue = initialTime => {
    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;
  }

  const Countdown = ({time}: {time: number}) => {
    return time > 0 ? Time left {time} : Done
  }
  
  const ActualCountdownInContextSomewhere = () => {
    const remainingSeconds = useCountdownValue(60)
    return 
      
    
  }
i'll say, i have never written a test for a hook or looked into what's needed to actually do that, but i suspect you don't need cypress or webdriver to test something like this has the correct output
or likewise you can probably use sinon or jest's fake timers to test the hook (however it is hooks are tested without triggering that error about not calling hooks outside of a function component, i guess you need to mock React.useState?).

but like, whatever works for your team! i think it's fair to argue for either direction, but neither is zero-cost unless you have buy-in for one direction vs another from your coworkers, which honestly is all that matters especially if you have to eat lunch with them occasionally.

Post reply on HN