Back when you were a young schoolchild, you probably learned to write by using a pencil on paper. Now that you’re older, it’s likely you prefer pens. For learners, pencils have a distinct advantage over pens in that mistakes are easy to correct, and when you first start writing out letters and words, you will be making a lot of mistakes. Pencils are also safer for small children – no caps or messy ink to worry about.
But pencils remain a valid writing instrument, and you might still have a personal preference for pencils over pens. The pencil is a perfectly good tool for the job.
Test-Driven Development (TDD) is a tool that can serve you in a similar way. It’s a great way to learn and grow as a developer. Many experienced developers prefer it for their day-to-day work over any alternative.
In this chapter, you’ll configure a work environment that’s designed to help you get the most out of TDD techniques. Since TDD asks you to do a bunch of small repetitive tasks – writing tests, running tests, committing early and often, and switching between test code and application code – it’s important that each of those tasks can be done easily and quickly.
It follows that an important personal discipline to cultivate is that of objectively critiquing your development tools. For every tool that you use, ask yourself this: is this tool serving me well? Is it easy and quick to use?
This could be your Integrated Development Environment (IDE), your operating system, your source code repository, your note-taking program, your time management utilities, and so on. Anything and everything you use in your day job. Scrutinize your tools. Throw away whatever isn’t working for you.
This is a very personal thing and depends a lot on experience and individuality. And your preferences are likely to change over time, too.
I often reach for very plain, simple, keyboard-driven tools that work for me consistently, regardless of the programming language I’m working in, such as the text editor Vim. It doesn’t offer any knowledge about the JavaScript programming language or the Svelte framework, but it makes me extremely effective at editing text.
But if you care about learning JavaScript or program design, then you might prefer an IDE that gives you JavaScript auto-complete suggestions and helpful project assistance.
This chapter walks through the setup of a new SvelteKit project and highlights all the individual choices you’ll need to make, and the additional extras you’ll need in order to practice effective TDD.
It covers the following topics:
- Creating a new SvelteKit project
- Preparing your development environment for frequent test runs
- Configuring support for Svelte component tests
- Optional configuration you may want to try
By the end of the chapter, you’ll know how to create a new Svelte project that is ready for test-driven feature building.
United States
Great Britain
India
Germany
France
Canada
Russia
Spain
Brazil
Australia
Singapore
Hungary
Ukraine
Luxembourg
Estonia
Lithuania
South Korea
Turkey
Switzerland
Colombia
Taiwan
Chile
Norway
Ecuador
Indonesia
New Zealand
Cyprus
Denmark
Finland
Poland
Malta
Czechia
Austria
Sweden
Italy
Egypt
Belgium
Portugal
Slovenia
Ireland
Romania
Greece
Argentina
Netherlands
Bulgaria
Latvia
South Africa
Malaysia
Japan
Slovakia
Philippines
Mexico
Thailand
Filter
