I'm new to testing front-end. It's amazing how complicated it is and how uncomplicated everyone makes it out to be. If you visit any of the testing framework websites they would have you believe you are just an npm install and 5 lines of code away from testing. It's the biggest lie in front-end development.
When you develop a true production app (not a webpage) you have information coming from so many vectors that all shape the current state of the UI. Local storage hydrating state, fetches, props, etc.
For example, I have a rather large svelte application with an entry-point for App.svelte. The first thing the user sees is wholly dependent on the svelte stores and what data they are pulling from local storage. If there is nothing in the settings key then they see a first time setup screen flow. If settings is there then they see a main page, or the previous page they left off on. That previous page maybe be a child page and have props.
A good functioning app needs to take all of these things into consideration and I don't see a SIMPLE way to test it all.
My ideal testing framework would make it easy and simple to test each component individually and have you setup the state contexts and then mount the component. I just want to do this every time.
For Each Test:
Mock Local Storage
Mock fetch responses (these are called stubs or something??)
Mock Prop state
Mount Component
Run Tests
UnMount
You're probably going to say that this is possible. And you might even say that the articles I just read show me how to do it. That may be true but I just finished creating a complex app in Svelte using many technologies I had to learn and had to overcome daily challenges to get it out the door. None of that knowledge or syntax seems to translate over to the testing at all. Instead I seem to have to learn how to wire 5 more things together, install a bunch more dependencies and learn a whole new syntax and methodology.
This isn't an indictment on your series. I will no doubt use the information in these articles to test like 15% of my app because it's all I'm going to be able to cobble together in the short amount of time I have allotted for testing (just being real). This is just a venting of frustration for what is involved to test something in the first place because, given Svelte's mandate, I'm disappointed that the state of testing is so disjointed.
I appreciate people like YOU that can pick up the pieces, put together the puzzle and communicate the picture to clueless devs like myself. Lots of love we need people like you in the Svelte community.
Now to start figuring out how to implement roll-up for my testing after just creating an entire app with webpack (FML).
Hey Jeff, thank you for this. I think your comment will resonate with many people, especially those whoβve been successfully testing back-end codebases and then moved to the front-end.
I know youβve already built your app, but the best advice for testable front-end codebases is this: Keep your components as simple as possible. Think of hexagonal architecture, ports-and-adapters, etc. Do any local storage access or fetch requests OUTSIDE of your components. That way your components become smaller in relative size and you might even choose to not unit test them at all.
Unit testing components is so hard that people prefer to use system/acceptance tests instead. IMHO this then results in overtesting and brittle tests, and end up costing you more in the long run.
Iβd encourage you to keep exploring and to keep posting about your experiences. I for one would love to hear more as you progress, and Iβm sure others would too.
Now 6 years ago the motivation was to be able to test functionality without the DOM but I think the benefit of a boundary between DOM (& events) and view/application state can still exist today - i.e. there can be a case to keep your (view) components thin.
I'm not sure what you mean by keep components as simple as possible.
Basically local storage is hydrated to stores and the stores are imported to my components. That's the recommended way for a svelte app.
I'm not 100% what I even need to test.
TBH early on I was able to implement cypress. And I did something people don't recommend, but worked for me, which was to load the app and step through it in code. This at least verified for me that things like first time setup would run. Problem was that to test any work-flow each test case would have to initially run the "first time setup" and then next test the workflow I wanted.
Unfortunately I installed an npm package (Monaco_Editor) that I need and it seems to have broke cypress and now I'm stuck with a generic cypress error and no test will run at all.
This leaves me with no avenue for support. Cypress points to Svelte or Monaco-Editor, Monaco-Editor is going to point to the other two.
It's just a mess.
I decided to try and scrap cypress and just try and test the components themselves opposed to a "workflow". But I don't think that's possible... I might look into just testing the stores themselves without the components because they do drive the app. Any suggestion on how I can do that or where I would look to find out?
I completely missed your reply π€¦ββοΈ Itβs over a month later now -- let me know if youβve made any more progress.
If all your business logic is in stores then itβd be perfectly reasonably to not test components at all, or just have a few end-to-end tests rather than unit tests.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm new to testing front-end. It's amazing how complicated it is and how uncomplicated everyone makes it out to be. If you visit any of the testing framework websites they would have you believe you are just an npm install and 5 lines of code away from testing. It's the biggest lie in front-end development.
When you develop a true production app (not a webpage) you have information coming from so many vectors that all shape the current state of the UI. Local storage hydrating state, fetches, props, etc.
For example, I have a rather large svelte application with an entry-point for App.svelte. The first thing the user sees is wholly dependent on the svelte stores and what data they are pulling from local storage. If there is nothing in the settings key then they see a first time setup screen flow. If settings is there then they see a main page, or the previous page they left off on. That previous page maybe be a child page and have props.
A good functioning app needs to take all of these things into consideration and I don't see a SIMPLE way to test it all.
My ideal testing framework would make it easy and simple to test each component individually and have you setup the state contexts and then mount the component. I just want to do this every time.
For Each Test:
You're probably going to say that this is possible. And you might even say that the articles I just read show me how to do it. That may be true but I just finished creating a complex app in Svelte using many technologies I had to learn and had to overcome daily challenges to get it out the door. None of that knowledge or syntax seems to translate over to the testing at all. Instead I seem to have to learn how to wire 5 more things together, install a bunch more dependencies and learn a whole new syntax and methodology.
This isn't an indictment on your series. I will no doubt use the information in these articles to test like 15% of my app because it's all I'm going to be able to cobble together in the short amount of time I have allotted for testing (just being real). This is just a venting of frustration for what is involved to test something in the first place because, given Svelte's mandate, I'm disappointed that the state of testing is so disjointed.
I appreciate people like YOU that can pick up the pieces, put together the puzzle and communicate the picture to clueless devs like myself. Lots of love we need people like you in the Svelte community.
Now to start figuring out how to implement roll-up for my testing after just creating an entire app with webpack (FML).
Hey Jeff, thank you for this. I think your comment will resonate with many people, especially those whoβve been successfully testing back-end codebases and then moved to the front-end.
I know youβve already built your app, but the best advice for testable front-end codebases is this: Keep your components as simple as possible. Think of hexagonal architecture, ports-and-adapters, etc. Do any local storage access or fetch requests OUTSIDE of your components. That way your components become smaller in relative size and you might even choose to not unit test them at all.
Unit testing components is so hard that people prefer to use system/acceptance tests instead. IMHO this then results in overtesting and brittle tests, and end up costing you more in the long run.
Iβd encourage you to keep exploring and to keep posting about your experiences. I for one would love to hear more as you progress, and Iβm sure others would too.
I think this is a related concept: Segregated DOM
Now 6 years ago the motivation was to be able to test functionality without the DOM but I think the benefit of a boundary between DOM (& events) and view/application state can still exist today - i.e. there can be a case to keep your (view) components thin.
Hey thanks for the response.
I'm not sure what you mean by keep components as simple as possible.
Basically local storage is hydrated to stores and the stores are imported to my components. That's the recommended way for a svelte app.
I'm not 100% what I even need to test.
TBH early on I was able to implement cypress. And I did something people don't recommend, but worked for me, which was to load the app and step through it in code. This at least verified for me that things like first time setup would run. Problem was that to test any work-flow each test case would have to initially run the "first time setup" and then next test the workflow I wanted.
Unfortunately I installed an npm package (Monaco_Editor) that I need and it seems to have broke cypress and now I'm stuck with a generic cypress error and no test will run at all.
This leaves me with no avenue for support. Cypress points to Svelte or Monaco-Editor, Monaco-Editor is going to point to the other two.
It's just a mess.
I decided to try and scrap cypress and just try and test the components themselves opposed to a "workflow". But I don't think that's possible... I might look into just testing the stores themselves without the components because they do drive the app. Any suggestion on how I can do that or where I would look to find out?
Thanks again.
I completely missed your reply π€¦ββοΈ Itβs over a month later now -- let me know if youβve made any more progress.
If all your business logic is in stores then itβd be perfectly reasonably to not test components at all, or just have a few end-to-end tests rather than unit tests.