This content originally appeared on DEV Community and was authored by kevin074
Have been interviewing for quite a while. What stood out to be in this painful process was that the interview is doomed if the question of testing was raised at all. This is because my experiences have been primarily in frontend development and the two companies I have stayed in were very poor in frontend testing.
--- Skip if you want to go straight to the discussion ---
My lack was, in some sense, a byproduct of industry culture. Frontend testing has always been a thing, but back a decade ago company structure has been separating testing concerns from development process. So we had a dedicated QA team who would write E2E/automated tests for us developers. So testing was not even in the job description. Also the unfortunate truth of small startup is delivery is always above everything else, so since testing hinders productivity, we developers didn't test. We didn't even have any testing librarie (Jasmine/Mocha/PhantomJS...) installed in the repo.
I got my second job in a much bigger company (consumer platform team had like 150 developers?). However, there was no testing too essentially speaking. Each team (teams divided by feature like checkout, loyalty, registration...) again had dedicated QA member(s) who would write those E2E test. Once that culture set in and QA was cut from the budget, no one was picking them up because there was no one to learn it from. I tried to pick up some E2E testing for our team, but the code left behind wasn't even functional and full of obvious bugs (lots of WTFs). Combined with tight deadlines AGAIN, testing fell behind. The only time people talked about testing was for utility functions and custom react hooks.
--- discussion starts ---
Being plagued by the no-testing culture, I have to at least come up with something that I can say during interviews about testing abstractly. I'll skip over the usual bullshits of not testing styles or implementation what not.
Feel free to add to the discussion. This affects at least 300 of my past coworkers!
1.) test global states:
In my experiences one of the most gnarly feature is "if this happens, we'll do this for you automatically" type of behavior. For example, one app I had was a graph visualization dashboard that was heavily configurable. One configuration change can cause other configurations to change as well, depending on the data returned and what not. Some configuration side effects are not straight forward. So you'll want to test automatic configuration changes and whether the state is persisted/unchanged/consistent across the board. So if you have testing around this type of behavior, aligned with PM, managers, design, and QA team is immensely vaulable.
2.) don't spend much time testing the integrity of UI input:
I see quite a few tutorials talking about testing inputs, like when I type "taylor swift" into the search bar and press enter, then our search function will get taylor swift as input.
This is straight up unhelpful. If your data binding is broken it'll either be very obvious that you should have caught it yourself while development or it's not automatically testable because something was hindering the functionality, like an invisible div above search bar so users can't type in search.
if you are being paid by lines of code though, go ahead :)
3.) test inputs as side effect of inputs though is desirable:
contrary to number 2, you'll want to test functional calls that are completely side effects to user interaction. For example, when user clicks on a button, a request should be called to register this user action for data analysis. This type of side effect that are completely separate from the core functionality, should be automatically tested so that we won't be caught off guard by some unintentional changes. Non-core side effect can be essential to other teams, I was on one of such other teams :D
So how do you architect these testing requirements?
let's break down the frontend architecture: MVC (you can say you are MVVM or what not, it doesn't really matter).
V - view (html/jsx): This is great for E2E/headerless browser testing and is an industry standard.
C - controller (business logic): spend some time making sure the functions are correct. For example, if you have/abstract to pure functions, does the expected input-output process still in tact? Somewhat industry standard, but people don't usually bother making stateful functions into pure functions and test.
M - model (api calls/states): this is what I want to focus on the most. your (non-rendering) states should be global and singleton per concept. Not new idea, since Redux is basically it. However it doesn't have to be Flux for our testing purposes. You can have jotai atoms but you can code a wrapper so that you can expose your centralized setter functions for testing.
the similar thing should be done on your api calls/third party libraries. It should be global and singleton so that you can confidently tests "when I do this, is a core/noncore api call made in the application". This is done routinely in, my limited experience, backend applications. It should be done in frontend applications too.
How does this sound? I am sure someone already does this already, what's your experience? what can be improved? I'd love to hear from folks where frontend testing just go beyond E2E/headless browser and braindead simple unit testing.
This content originally appeared on DEV Community and was authored by kevin074
kevin074 | Sciencx (2024-09-13T16:15:14+00:00) On to effective frontend testing. Retrieved from https://www.scien.cx/2024/09/13/on-to-effective-frontend-testing/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.