Tests in components

[arxpoetica]

Just a placeholder for now on this idea: https://gitter.im/sveltejs/svelte?at=5aae6e8ae4d1c6360412d107

Will return to this soon.

[TehShrike]

When it comes to components themselves, the only assertions I generally care to make are about the shape of the data being passed in to it.

Something like React's PropTypes would fit the bill.

Related: #880

[arxpoetica]

@TehShrike Components lend themselves most easily to unit tests; that's the most logical scope, i.e., test the thing itself. "Unit test" definition here would be a little squishy, but it means it mostly knows about its own implementation details, and nothing outside the scope of the component.

This may sound contradictory, but I also agree mostly with this idea: https://twitter.com/rauchg/status/807626710350839808 That is, don't write too many unit tests. But write enough for the most important I/O of the component, so in that sense, I agree with your point about data. But there might be other considerations.

Just the same, a larger set of integration or E2E tests might be worth considering. Before we throw it out entirely, I think it's worth doing a little bikeshedding. I haven't had time to fully think through this, and arguably, this is something Sapper is more suited to instead of Svelte alone, but I want to give it some time to simmer.

One idea is to simply provide connection points, sort of like an API, for components to communicate test behaviors and I/O to. Like I said, I really haven't had time to think this through, but maybe something like:

<Component1 t-out:method:foo t-out:var1></Component1>

<Component2 t-in:method:foo t-in:var1></Component2>

I really actually don't like the above because it's not loosely coupled, but I'm trying to actually bring something to the discussion. I'd love to hear other ideas. Including Sapper like implementation, which can be taken up somewhere in a Sapper ticket if it becomes a thing to talk about over there.

🤓

[arxpoetica]

Oh, by the way, in terms of tests inside the component, that one does seem to have some more obvious approaches. A potential example:

<p>a = {{a}}</p>
<p>b = {{b}}</p>
<p>a + b = {{added}}</p>

<button on:click="set({ b: b + 1 })">Increase var b by 1</button>

<script>
	export default {
		data() {
			return {
				a: 1,
				b: 1,
			}
		},
		computed: {
			added: (a, b) => a + b,
		},
		tests: {
			addedComputed() {
				[...run test in here...]
			},
		},
	}
</script>

Again haven't thought through fully correct permutations. What exactly needs testing? How does one differentiate between computed, method, and helper testing? How do we keep this testing framework agnostic? Etc.

[TehShrike]

I write a good number of unit tests, but they're almost always for business logic/complex data transformations, and I put that logic in their own files outside of the component.

Besides development mode assertions that my app provided components the data that they expected, the only things I can think of that I would want to assert about a component would be:

1. produces the HTML I expect when rendered. (this is currently easy to test with Svelte, I just don't think I've written anything yet that would give me any value if I wrote these tests)
2. any unusual DOM interactions that I've hooked up work correctly in every browser. (I do write these tests occasionally, but in this case I actually think that these tests are more appropriate outside the component, being in charge of instantiating the universe/browser environment that the component will be tested in)

For the vast majority of the unit tests I write, the assertions themselves don't take up much space. Most of the lines in the tests are dedicated to defining the set of inputs and expected outputs of the function. I wouldn't want to clutter up my component with this test data.

I would get a ton of value from first-class PropTypes-like functionality, though. It's a great way to document component data shapes, and it catches annoying bugs early during development.

(random aside about that rauchg tweet: people have completely different ideas about the difference between integration/unit tests https://twitter.com/TehShrike/status/880510235328356354 )