Thanks for the reply. There’s a lot in this so perhaps I can just pick up a few things:
The distinctions between unit & everything else is possibly more useful than other distinctions. I think the key distinction of “unit” is that they are isolated and so are protected from change / breakage. Non-unit tests are more brittle in the sense that because they execute a larger surface area, they are more likely to require change as the codebase changes. This is why we think of unit tests as cheaper.
It’s the guidance of preferring integration tests that I am challenging in this post. I’m suggesting that this advice came about not because unit tests don’t make sense on the front-end, but because they often prove extremely difficult for people to get right. I.e. they end up mocking everything, or writing convoluted tests, or their tests get in the way of refactoring, and so on.
On the point of frameworks -- I exist in the camp of people that believes that we should always ”minimize” frameworks as much as possible. In the case of React that means try to suck as much code out of React components as possible. That way you avoid lock-in and unit testing becomes simpler.
It’s the guidance of preferring integration tests that I am challenging in this post. I’m suggesting that this advice came about not because unit tests don’t make sense on the front-end, but because they often prove extremely difficult for people to get right.
They definitely are. To me, the key reason to write tests is because they add value. If I have code like:
<div v-for="foo in foos">{{ foo.bar }}</div>
writing a test with mocked data feels like I am testing that Vue.js isn't broken and that v-for works. That's Vue's responsibility to test, and I won't bother - it doesn't add value to me.
I may write a test that mocks an API call to make sure it renders everything correctly, but again, that, to me, is an integration test.
I'd be curious to see what you consider a good unit test for frameworks. (I'll be sure to look through your Svelte testing series, even though I am not currently interested in learning another framework - maybe I'll find an answer there.)
I exist in the camp of people that believes that we should always ”minimize” frameworks as much as possible.
I can respect that position. As I'm not good at design, and don't care to spend 2 months writing apps that work well on OSX, and iOS, and Safari, and IE11, etc., I personally like frameworks that offer a lot of abstractions, and let me focus on features. I love working with Quasar (based on Vue). But that's a personal choice, and I don't think there is one good answer - we've all got our own strengths, weaknesses, and preferences.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the reply. There’s a lot in this so perhaps I can just pick up a few things:
The distinctions between unit & everything else is possibly more useful than other distinctions. I think the key distinction of “unit” is that they are isolated and so are protected from change / breakage. Non-unit tests are more brittle in the sense that because they execute a larger surface area, they are more likely to require change as the codebase changes. This is why we think of unit tests as cheaper.
It’s the guidance of preferring integration tests that I am challenging in this post. I’m suggesting that this advice came about not because unit tests don’t make sense on the front-end, but because they often prove extremely difficult for people to get right. I.e. they end up mocking everything, or writing convoluted tests, or their tests get in the way of refactoring, and so on.
On the point of frameworks -- I exist in the camp of people that believes that we should always ”minimize” frameworks as much as possible. In the case of React that means try to suck as much code out of React components as possible. That way you avoid lock-in and unit testing becomes simpler.
They definitely are. To me, the key reason to write tests is because they add value. If I have code like:
writing a test with mocked data feels like I am testing that Vue.js isn't broken and that
v-forworks. That's Vue's responsibility to test, and I won't bother - it doesn't add value to me.I may write a test that mocks an API call to make sure it renders everything correctly, but again, that, to me, is an integration test.
I'd be curious to see what you consider a good unit test for frameworks. (I'll be sure to look through your Svelte testing series, even though I am not currently interested in learning another framework - maybe I'll find an answer there.)
I can respect that position. As I'm not good at design, and don't care to spend 2 months writing apps that work well on OSX, and iOS, and Safari, and IE11, etc., I personally like frameworks that offer a lot of abstractions, and let me focus on features. I love working with Quasar (based on Vue). But that's a personal choice, and I don't think there is one good answer - we've all got our own strengths, weaknesses, and preferences.