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.
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.