I don't think there is a one-size-fits-all approach, when it comes to testing.
If you are writing utility functions, those should definitely be covered with unit tests.
If they are useful, you might want to make them a separate library, and not keep them with your web projects, however.
If you are writing a JS framework (Vue, React, Angular, etc.), you should definitely write unit tests to cover it.
If you are leveraging a framework, you shouldn't be writing tests that the framework does what it's supposed to do, so you'll probably end up writing more integration tests.
Modern front-end applications involve user workflow, receiving and sending data through network requests, handling session state and data validation. For applications that involve content creation, there’s plenty of business logic to contend with, too.
All of these lend themselves well to unit testing.
To me, that sounds more like integration tests than unit tests.
Whatever is back-end / API will be tested by unit tests in pytest (as I use Django for my back-ends - maybe I'll eventually take the plunge with something like Node or Express).
I guess you can mock network requests, and call it a unit test... lines get kind of blurry at that point :D
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.
I don't think there is a one-size-fits-all approach, when it comes to testing.
If you are writing utility functions, those should definitely be covered with unit tests.
If they are useful, you might want to make them a separate library, and not keep them with your web projects, however.
If you are writing a JS framework (Vue, React, Angular, etc.), you should definitely write unit tests to cover it.
If you are leveraging a framework, you shouldn't be writing tests that the framework does what it's supposed to do, so you'll probably end up writing more integration tests.
I highly recommend Kent C. Dodd's *Write tests. Not too many. Mostly integration. blog post / talk.
To me, that sounds more like integration tests than unit tests.
Whatever is back-end / API will be tested by unit tests in
pytest(as I use Django for my back-ends - maybe I'll eventually take the plunge with something like Node or Express).I guess you can mock network requests, and call it a unit test... lines get kind of blurry at that point :D
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.