Implementing Test Driven Development in Svelte

Test Driven Development. It is defined as a technique in development process where you need to write a test that fails first in order to be able to move to the next step, which is writing the functional code. Well, there are 3 steps in implementing TDD, which we perhaps have been familiar with, Red, Green, Refactor, which include:

  1. Write Failing Test
  2. Write functional codes that pass the test
  3. Improve the functional code

Those 3 steps would be repeated over and over during the development process.

As a front-end developer in my team for this Software Engineering Project, I could not imagine how can we implement testing to build front-end interfaces, because from what I’ve understood, the front-end development includes UI development, which involves element positioning, colors, layout, texts, etc. How shall we test those things? It’s very different from the TDD I’ve learned on Web Development and Design course just a little more than a year ago, where we only tested the back-end stack of the web, which we wrote in Python using Django.

But after the first sprint of the development process began, I started to learn more about testing, especially unit testing in Svelte (a JavaScript-based front-end framework my team is using for the project). Turned out that it could be done using Jest and Svelte Testing Library. And at first, I thought in implementing TDD in this front-end stack of the project, we only need to write tests for the JS functions we are going to implement. But it turned out wrong. Of course to reach 100% code coverage (which is mandatory for this project), we need to write tests for all the lines we are going to write. So the steps I have been doing to implement TDD in Svelte so far are:

  1. Plan and describe the components needed.
  2. Plan the behavioral aspect of each component (whether it’s only going to be rendered or whether it needs to run a function, like buttons, etc.)
  3. For static component, I made a unit test to test whether the component is rendered in the DOM (that is not yet made, so the test would go red/fail).
  4. For components like buttons, where it’s intended to run a function when clicked, I made a simulation unit test with an input/initial value, and assert it with the value outputted after the function is being ran.
Unit test examples.

UPDATE (22/03): After the tests are written, I supposedly commit and push them into the repository using a commit message started with [RED], but has been down since Friday (19/03), so instead of slowing down the development process, I’ve decided to just write the functional codes before committing the test (for this time only, until it gets back to normal).

UPDATE (05/04): The GitLab CSUI server is back up! So now I am going to reaaally explain how do I implement TDD on my project. Okay so, like what I have described above, I have done and still will be doing the planning and describing the component and its behaviors step. And I have also continued the development process so I have created more function.

Now I’m going to show you another unit test of mine:

Testcase for HomeView.svelte

In this unit test, I didn’t have to test each of the component anymore, but I only have to just test all of the components that’s going to be rendered into a page, in this case into the Homepage. So, I do not have to create separate files for each component. I only have to create one file for the page’s test, in this case, HomeView.test.svelte.

After that, I committed the changes of the failing tests into the repository, with [RED] tag in the commit message, like below:

After that, I implemented the functioning code inside the HomeView.svelte file, and make sure that the pipeline has passed and there is no failing test anymore:

After that, I committed the change and pushed it into the remote repository with the [GREEN] message tag:

In the commit above, the pipeline for unit test has passed, but the tag became orange because there was still errors in the checkstyle/linter job.

And then, I made some modification onto the codes. To commit that, I was using the [REFACTOR] tag on the commit message like below:

And if we wanted to make some modification to the test files, although the pipeline is green, my teaching assistant told me to still commit the changes using the [RED] tag on the commit message, like the following:

Well that’s how I implemented TDD on my current project! And it is going to be like that and would be on repeat over and over until the project is done and ready to release! :)

Despite the time-consuming stereotype, implementing TDD has many advantages for your project, such as:

  • Less debugging time.
  • You’d only write the code that’s needed.
  • The code becomes easier to check.
  • It documents your code.
  • Easier to refactor.
  • Higher test coverage.

That’s all for today’s article about my experience in (trying) to implement TDD in my Svelte project so far. Things might not go as planned because of some technical problem for now. I would try to improve it next time. Thank you for reading!

a computer science major in university of indonesia.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store