Test-driven development (TDD) writes tests alongside the code they validate. For Web Components, the most useful unit tests often run in the browser, while functional tests can check meaningful user outcomes such as clicking a button and observing a result. section 13.1
A component-testing setup separates several responsibilities:
- Web Component Tester launches browsers through Selenium and reports their results to the terminal. section 13.2
- Mocha organizes suites and tests, with setup and teardown hooks for clean test runs. section 13.2
- Chai supplies assertions that compare expected results with values returned by variables or functions. section 13.2
- WCT can be added as a development dependency and run against component test files from an npm script. section 13.2
Listing 13.2. WCT test file setup
<html>
<head>
<script src="../../../../node_modules/web-component-tester/browser.js">
</script> #1
<script #2
type="module"
src="../src/slider.js">
</script>
<style>
wcia-slider {
width: 500px; #3
}
</style>
</head>
<body>
<wcia-slider value="50"></wcia-slider> #4
<script>
// tests go here #5
</script>
</body>
</html>
Use the minimal HTML fixture to load WCT, import a component, configure its display, and place an element under test. section 13.2
Testing a slider component
A slider fixture starts at value 50. Tests verify its JavaScript property, HTML attribute, and rendered thumb position. Additional tests set the value to 20, then check that all three representations agree. Boundary tests deliberately set 110 and -10; their expected results are 100 and 0. These failing tests expose missing maximum and minimum handling, giving the implementation a concrete behavior to satisfy. section 13.2
The technique treats component behavior as discrete units and develops tests for each unit. It remains one option among many testing methodologies, with browser execution especially relevant when component behavior depends on the browser. section 13.1 section 13.4
