DEV Community

Tips for writing great Svelte tests

Daniel Irvine 🏳️‍🌈 on January 17, 2020

In the last part in my series on Svelte testing, I’ll round off with some smaller pieces of advice. To see all the techniques used in this series,...

Read full post

Gábor Soós • Mar 2 '20

Hi, thanks for the great tutorials on Svelte!

Yesterday I've also started playing with the framework, but I've stuck with component testing.
My problem is how to test dispatched events from a Svelte component? I haven't found any example for it.

github.com/blacksonic/todoapp-svel...

Daniel Irvine 🏳️‍🌈 • Mar 3 '20

Hey Gábor,

You can do it by using component.$on:

  it('should notify about delete button', async () => {
    const todo = { id: 'e2bb892a-844a-47fb-a2b3-47f491af9d88', name: 'Demo', completed: false };

    const { component, getByTestId, container } = render(Item, { todo });

    let wasCalled = false;
    component.$on("remove", ()=> { wasCalled = true; });

    fireEvent.click(getByTestId('todo-remove'));

    expect(wasCalled).toBeTruthy();
});

Whether or not you’d want to do this is another question. Svelte gives you a lot of rope... dispatch is an example of that. That fact that testing is hard is a sign that there may be a better approach with the design.

(Note--a better approach with the design, not a better approach with testing. An important difference!)

The question in my mind is does Item need to know that it exists within a List? It feels like List and Item can’t exist without one another, and each has a lot of knowledge about the other one. Is there a way to reduce the coupling? For example --- can remove functionality be moved entirely to List somehow?

You could also use stores to introduce shared state between the two, and remove the need for dispatch entirely.

Let me know your thoughts :)

Gábor Soós • Mar 4 '20 • Edited

I've tried it out, works like a charm!

One more question: is it possible to test a component with getContext without a wrapper component?

Here is an example: github.com/blacksonic/todoapp-svel...

Daniel Irvine 🏳️‍🌈 • Mar 4 '20

Glad to hear it worked! 🎉

Not sure about getContext. I vaguely recall looking into it and figuring out that getContext expects to be called as part of a render cycle of a component tree, which you can’t easily fake.

If you’re comfortable with relying on internal APIs like $on then one thing you could do is use the tutorial view for context (svelte.dev/tutorial/context-api). Choose JS output and explore the JS code that Svelte products for your component. Dig through to learn how setContext and getContext work. It might give you a solution. Failing that, use the Svelte source on GitHub. Let me know if you figure something out--I’d be interested to know.

Gábor Soós • Mar 3 '20

Thanks for the example, I'll try it out tomorrow.

In my opinion events (or function props) and props mean loose coupling as they only know each others interface and shared state is a strong coupling. Why do you think they know about each other? Yes, they know each other's interface, but it's necessary to communicate.

With other frameworks (Vue, Angular, React) I've found it easy to test events or function props, what I was missing is the $on method.

Daniel Irvine 🏳️‍🌈 • Mar 3 '20

Item knows about a remove operation, which means it "knows" that it exists in some kind of container (List or otherwise).

Not saying I know of a better solution or that I wouldn’t write it that way myself... just that I’m a little wary of dispatch and I’d keep my eyes open for opportunities to design it differently.

Daniel Irvine 🏳️‍🌈 • Mar 3 '20

Another point: unless I’m mistaken, $on is part of the internal Svelte API so if you use it, you have to be prepared to figure out a new solution if/when the maintainers break this one 🤣

Jeff Scott • Jan 20 '20

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

Daniel Irvine 🏳️‍🌈 • Jan 20 '20

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.

peerreynders • Jul 9 '20 • 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.

Jeff Scott • Jan 20 '20 • 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.

Daniel Irvine 🏳️‍🌈 • Mar 3 '20

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.