5
24 Comments

What tools do you use to test your frontend?

Hi,

I would like to know what kind of tools do you use to test your frontend? And if you test your frontend with a tool at all :)

I used ghostinspector.com and browserstack.com for bigger projects in the past, but they're not really suitable for small projects, landing pages.

Have a nice day,
Andras

posted to Icon for group Developers
Developers
on July 7, 2020
  1. 10

    Cypress. I tried Puppeteer, Playwright and a few others but they had weird 'quirks'. So does Cypress, but Cypress charmed me with their AMAZING documentation. THIS is how documentation should ALWAYS be written. And it is needed, since testing front-ends back-to-back is not easy, and you need someone to hold your hand. At least I did.

    I've spent A LOT of time getting it all set up, and the documentation starts growing thin around the extreme use of the tool, but the source code is there to be checked...

    One big thing though: if your tests are flakey, try a 'wait one second' command. I know the docs say it is the worst thing to ever do, but you often have the choice of adding it and or do it the proper way but spending a day finding out how to make it deterministic and only saving yourself a second per test.

    Also, running the tests in headless mode is A LOT more stable than the headed.

    Finally, for snapshot testing, I ended up forking my own version of cypress-image-snapshot. The code in that package isn't difficult to hack yourself, and you then have absolute control over it. One thing you'll want to do is set up automatic sub-foldering per/browser per/head-mode since those screenshots WILL differ, so having them separated makes sense.

    Oh, and if you run vue or firebase, I've noticed sometimes that Cypress 'starves' the main thread retrying assertions to such a degree that firebase or vue changes never get propagated to the UI, basically causing a deadlock. To fix that, you need to create your own tasks that uses promises to wait for Vuex Store commitments to come through and only then re-test the assertions. That will free up the main thread to actually update the system. Look at the (sadly not documented) 'cy.verifyUpcomingAssertions' function for how to check assertions from a command before 'relinquishing' a command value.

    1. 2

      I've used Cypress tests and Jest+Puppeteer+jest-image-snapshots tests on client projects before. Cypress is definitely the better option. That being said, the dev teams I've been part of never ended up using Cypress properly or for a long time. The main reason was that maintaining its tests was too time-consuming for a lot of devs (specially those with less automated testing experience).

      I built a tool that will hopefully help some teams with that problem: BrowseAI.com/test

      It's like Cypress in the sense that it can run your automated tests, take visual snapshots, record videos, and play your test video and show you the exact steps that lead to test success/failure. I'm also offering a free plan for up to 200 jobs per month for early users.

      What it does better than Cypress is that:

      • It's a no code tool. It uses a Recorder extension that can record your actions and generate dozens of selectors for each element you interact with (by label, by text, by position, by xpath, ...).
      • It automatically figures out how long it has to wait after each action for the results to appear.
      • Its tests are easier to maintain, because when you make slight changes to your code it automatically uses alternative selectors to update the test accordingly.
    2. 1

      Fantastic, did not know about cypress. Looks amazing.

      1. 1

        Me neither before this post. It seems like cypress is a popular choice for many developers nowdays.

    3. 1

      Thanks for the detailed answer.

      Do you run cypress manually or after each push?
      We tried different selenium variations, puppeteer too. We always tried to avoid the '1 second wait' thing, but as you said we couldn't avoid it all the time.

      1. 1

        I'm a one-man show right now with a local GIT (very well back-upped!) and no CI set up (yet!) so I do it manually for now. But, eventually I will move on to a CI and then I will run it as part of the CI build. I think. :-)

        Btw, the app I test is https://phojo.app , a photo journal, so it is pretty UI intensive with dialogs and image uploads, responsive PWA yadda yadda, and I think Cypress holds up fairly well. There may be something better out there, but after a few days of research, I couldn't find it and I'm happy I went with Cypress.

        1. 1

          Why do you use only a local git? Why don't you push your changes to a private github repo or smth?

          1. 1

            I figured that it wouldn't give me anything extra. One more service to add to the complexity pile for no gain. But maybe I've missed something really obvious? What would it give me, apart from a place to store code?

            Mind you, once I decide to have a CI build then I see the point of it as the repo from which my build server gets the code. But until then... 🤷‍♂️

            1. 1

              Here are the benefits i see even when i'm working on an MVP.

              • backup is done by github, you don't have to think about it
              • you can easily checkout and update the code from the github repo on prod server. When you're done with a feature you just push it and then you just simply do a 'git pull' on the server. Later, when you have more usage you can build a better CI pipeline.
              • pull requests are really handy even if you work on it alone, but you have users.
  2. 4

    unit testing feels a bit pointless for front-end. I feel like unit testing using something like jest is more for corporate sign-off and not for indie hackers. they use unit testing on the server so maybe they should on the client too lets give the dev team a code coverage target... but you're only doing i/o tasks on the front end and all the issues that come up are to do with prioritising whats run when in the event loop. testing a single unit of javascript always felt pointless to me because of how rare it is that any major problems comes from an isolated unit of code.

    for integration testing I've used Selenium but very keen to check out some of the other suggestions on here because... well you know. I've also built a custom chrome plugin in the past to do some more advanced integration testing relative to the project I was working on and found that for the effort it took to build it was totally worth it.... a far better use of time than writing any unit tests.

  3. 2

    Cypress +1. It's great for end-to-end testing.

  4. 2

    I'm running cypress on CI. At first I tried to test complex redirect flows with it (like auth and payment where users are jumping between my domain and other ones) but it didn't really work. Now I'm content with just testing the basic frontend features, but not go too far with it. Nice balance of benefits / time spent.

  5. 2

    Mainly TestCafe (one colleague once said, "the enemy of the good [Cypress] is the better") run after deployment or nighly through Jenkins.

  6. 2

    Hi Andras,

    I'm building a web scraping service (https://datagrab.io) and in order to get it out quickly (and furthermore, because in this early phase, the UI constantly changes), I haven't got any tests written yet (bad practice, I know :) ).
    I'm using React / Redux on the Frontend, so I'm looking into incorporating Jest and Enzyme as testing libraries. Coupled together, they are pretty good at testing the Redux store, action creators and even React components.

  7. 2

    I'm just using React Testing Library / Jest for my landing page right now. Eventually I'd like to move to https://www.cypress.io/ for full end to end testing in the browser

  8. 2

    For React apps I prefer running tests with Jest inside NodeJS.

    Libraries:
    https://github.com/facebook/jest
    https://github.com/jsdom/jsdom
    https://github.com/testing-library/react-testing-library
    https://github.com/jameslnewell/xhr-mock
    https://github.com/boblauer/MockDate
    https://github.com/clarkbw/jest-localstorage-mock

    Typical test:

    1. Mock the DOM
    2. Mock XHR requests
    3. Render the component (usually something big and isolated like a "page")
    4. Trigger events (button click etc)
    5. Assert DOM state
    6. Assert XHR order, urls, payloads
    1. 1

      Thanks for the list. How often do it? And for how big projects?

      1. 1

        So far I've applied it in 2 latest projects I've worked on.

        Multi-year projects maintained by 2-4 front-end/fullstack devs.

  9. 2

    If you mean testing frameworks, then I am a big fan of Cypress.

    Although I am not totally fond of their asynchronous handling, it's way better than anything I've used in the past.

    1. 1

      yes, I also meant testing frameworks using Selenium or similar.
      Did you use Cypress for bigger projects or smaller projects as well?

      1. 2

        I've only used Cypress for my current side-project which is a medium-sized codebase (30-50k of TypeScript code IIRC), never for any of my clients. I have something like 60-70 UI tests, so nothing crazy yet, although I intend to increase the coverage.

        There are a few particularly cool things about Cypress:

        • It's fast
        • The UI. You can run single tests, or all of them
        • Videos/Screenshot on failure out-if-the-box
        • Easy to add visual-regression-testing to it (for my project it is pretty crucial)
        • It does wait for UI changes by itself, but it's not magic

        Something else I really like is that it is opinionated. The team suggests how to write good tests and have plenty of videos and documentation for you to learn. Selenium has always been a bit of jungle in this regard.

        If you have any question I'll try to answer to the best of my knowledge (still learning myself) 😅

        1. 1

          How flaky are your tests? How many times do they fail without any known reason?

          1. 2

            Flakiness is still there although much less than Selenium.

            Most of the failures happen because Cypress can't click an element covered by another one, although you can force it to.

            Other than this, they don't really fail in many instances. Can't give you a number, but every time I think it's flaky there's a reason behind it in my code.

            This could be due to data changing in between runs, having to wait for an element to appear, etc

            As I said it's better than Selenium, but it's not magic. Testing UIs is still hard :)

  10. 1

    We're using Endtest and it has been a decent experience so far.

    URL: https://endtest.io

    We've tried to use Cypress, but it had too many limitations, like the fact that it did not work with multiple browser tabs and the fact that it did not work with Internet Explorer 11, Safari and mobile browsers.

Trending on Indie Hackers
I spent $0 on marketing and got 1,200 website visitors - Here's my exact playbook User Avatar 68 comments Veo 3.1 vs Sora 2: AI Video Generation in 2025 🎬🤖 User Avatar 30 comments I built eSIMKitStore — helping travelers stay online with instant QR-based eSIMs 🌍 User Avatar 21 comments 🚀 Get Your Brand Featured on FaceSeek User Avatar 20 comments Day 6 - Slow days as a solo founder User Avatar 16 comments From side script → early users → real feedback (update on my SaaS journey) User Avatar 9 comments