Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Svelte with Test-Driven Development

You're reading from   Svelte with Test-Driven Development Advance your skills and write effective automated tests with Vitest, Playwright, and Cucumber.js

Arrow left icon
Product type Paperback
Published in Jun 2023
Publisher Packt
ISBN-13 9781837638338
Length 250 pages
Edition 1st Edition
Languages
Arrow right icon
Author (1):
Arrow left icon
Daniel Irvine Daniel Irvine
Author Profile Icon Daniel Irvine
Daniel Irvine
Arrow right icon
View More author details
Toc

Table of Contents (22) Chapters Close

Preface 1. Part 1: Learning the TDD Cycle
2. Chapter 1: Setting up for Testing FREE CHAPTER 3. Chapter 2: Introducing the Red-Green-Refactor Workflow 4. Chapter 3: Loading Data into a Route 5. Chapter 4: Saving Form Data 6. Chapter 5: Validating Form Data 7. Chapter 6: Editing Form Data 8. Part 2: Refactoring Tests and Application Code
9. Chapter 7: Tidying up Test Suites 10. Chapter 8: Creating Matchers to Simplify Tests 11. Chapter 9: Extracting Logic Out of the Framework 12. Chapter 10: Test-Driving API Endpoints 13. Chapter 11: Replacing Behavior with a Side-By-Side Implementation 14. Chapter 12: Using Component Mocks to Clarify Tests 15. Chapter 13: Adding Cucumber Tests 16. Part 3: Testing SvelteKit Features
17. Chapter 14: Testing Authentication 18. Chapter 15: Test-Driving Svelte Stores 19. Chapter 16: Test-Driving Service Workers 20. Index 21. Other Books You May Enjoy

Using Component Mocks to Clarify Tests

The preceding chapter introduced the concept of a test double and showed how vi.fn can be used to swap out unwanted behavior within your Vitest test suites. The same technique can be used for Svelte components, but it’s a little more complicated.

Imagine you’re writing unit tests for a component named Parent, and that component itself renders another developer-defined component, named Child. By default, when your tests render Parent, Child is rendered too. But using a component mock can stop that from happening. It swaps out the real Child for a test double.

There are various reasons why you’d want to do this:

  • The Child component already has its own unit test suite, and you don’t want to repeat yourself (a form of overtesting, described in detail in the Avoiding component mocks section)
  • The Child component has behavior on mount, such as fetching data via the Fetch API, that you’d rather avoid...
lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image