DEV Community

Discussion on: Tips for writing great Svelte tests

Collapse
 
jeffwscott profile image
Jeff Scott

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

Collapse
 
d_ir profile image
Daniel Irvine πŸ³οΈβ€πŸŒˆ

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.

Collapse
 
peerreynders profile image
peerreynders • Edited

Think of hexagonal architecture, ports-and-adapters, etc.

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.

Collapse
 
jeffwscott profile image
Jeff Scott • Edited

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.

Thread Thread
 
d_ir profile image
Daniel Irvine πŸ³οΈβ€πŸŒˆ

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.