This video is great. As someone whose just reaching the level of coding where these considerations and distinctions have become relevant, this has been very insightful.
This is a helpful list of grey areas to consider with no specific guidance. Who gave you the idea that a single assert per test was a worthy goal or an indicator of focus ? Multiple asserts in one test greatly improve the developer feedback, guiding them specifically to the issue. Test the interface but move the type tests to a type checker ? How about both but certainly not crippling your interface tests because a dogged worship for typescript tooling. False result test failures should be resolved, but why the fear over failed tests to the point of removing them ? If you are making changes, you want to see tests fail and remediated.
Regarding Mocking, you are talking about Unit tests, in that case everything should be mocked since we are testing the unit. If you provide anything else it is in fact integration tests, which makes totally sense. A unit test has the purpose to test the function, not the dependencies. I totally agree on the types of asserts! I've been Unit testing for about 10 years now and lately it was the first time I saw tests that where asserting things that the type checker could take care. Especially when you worked in Angular those kind of tests seem quite awkward. I also saw some false results lately and I completely agree here as well. Regarding Understandability, you speak from my heart! When I learned unit testing the first thing I learned is that you write understandable sentences like 'it(should a proper name from id)' or 'it(should return null if id is not found)'. A common mistake that I have seen is that people think that unit tests are testing code (or even applications) but that's not the case. Unit tests are documention of the code, it explains how your code works, it gives you the ability to refactor the code. It gives you confidence to do changes (no more: i'm afraid to touch that piece of code).
"Unit tests are documentation of the code, it explains how your code works" This is something I've heard for years and I'm sure it's different depending on what kind of technologies and software you are building, but I am of the opinion these days that your code should be self-documenting in itself, optimizing readability as we all spend much more time reading code than writing it. I think there is a risk in relying on a test to do this documentation for you. Though worth mentioning that as a front-end developer, I have adopted Kent C Dodds' approaches to testing, which minimize unit testing anyway (the test trophy model).
1. mocking. Testing is not only about "testing" it's about writing specifications on what your code should do, this is specially useful when refactoring.
That was very helpful in regards to unit vs integration testing: "To mock or not to mock?" Any advice on how to organize or layout your tests? How do you organize unit tests? Where do you put integration or e2e tests? Do you even distinguish between the different "types" of tests? Do you group more integrated tests according to what components they test or according to the "story" they test?
Got yourself a new sub! I'm looking forward to learning a lot from you! I'm currently in my final year of university as an EE. Just got done learning OOP architectural patterns and implementing paradigms. Hoping to learn some good testing metrics and practices as well!.
I actually believe the concept of "integration tests" is kinda useless. Every single software component is integrated in someway for the first place. For me, the only meaningful distinction is e2e tests or unit tests, specifically, e2e tests are, say, examining requests and responses from JSON API server you're developing, and units tests are everything others.
This video is great. As someone whose just reaching the level of coding where these considerations and distinctions have become relevant, this has been very insightful.
This is a helpful list of grey areas to consider with no specific guidance. Who gave you the idea that a single assert per test was a worthy goal or an indicator of focus ? Multiple asserts in one test greatly improve the developer feedback, guiding them specifically to the issue. Test the interface but move the type tests to a type checker ? How about both but certainly not crippling your interface tests because a dogged worship for typescript tooling. False result test failures should be resolved, but why the fear over failed tests to the point of removing them ? If you are making changes, you want to see tests fail and remediated.
Regarding Mocking, you are talking about Unit tests, in that case everything should be mocked since we are testing the unit. If you provide anything else it is in fact integration tests, which makes totally sense.
A unit test has the purpose to test the function, not the dependencies.
I totally agree on the types of asserts! I've been Unit testing for about 10 years now and lately it was the first time I saw tests that where asserting things that the type checker could take care. Especially when you worked in Angular those kind of tests seem quite awkward.
I also saw some false results lately and I completely agree here as well.
Regarding Understandability, you speak from my heart! When I learned unit testing the first thing I learned is that you write understandable sentences like 'it(should a proper name from id)' or 'it(should return null if id is not found)'.
A common mistake that I have seen is that people think that unit tests are testing code (or even applications) but that's not the case. Unit tests are documention of the code, it explains how your code works, it gives you the ability to refactor the code. It gives you confidence to do changes (no more: i'm afraid to touch that piece of code).
"Unit tests are documentation of the code, it explains how your code works" This is something I've heard for years and I'm sure it's different depending on what kind of technologies and software you are building, but I am of the opinion these days that your code should be self-documenting in itself, optimizing readability as we all spend much more time reading code than writing it. I think there is a risk in relying on a test to do this documentation for you. Though worth mentioning that as a front-end developer, I have adopted Kent C Dodds' approaches to testing, which minimize unit testing anyway (the test trophy model).
1. mocking. Testing is not only about "testing" it's about writing specifications on what your code should do, this is specially useful when refactoring.
indeed, agreed! check out my other videos on tdd and unit testing to learn even more reasons of why we test :)
That was very helpful in regards to unit vs integration testing: "To mock or not to mock?"
Any advice on how to organize or layout your tests?
How do you organize unit tests? Where do you put integration or e2e tests? Do you even distinguish between the different "types" of tests? Do you group more integrated tests according to what components they test or according to the "story" they test?
Got yourself a new sub!
I'm looking forward to learning a lot from you!
I'm currently in my final year of university as an EE. Just got done learning OOP architectural patterns and implementing paradigms. Hoping to learn some good testing metrics and practices as well!.
Welcome aboard!
I think the only reasonable use case of mocks is mocking external APIs.
That's a bit strict. Having unit tests with high levels of isolation can be very helpful.
Need some code examples
Nicely explained! 👍
Great video!
I actually believe the concept of "integration tests" is kinda useless.
Every single software component is integrated in someway for the first place.
For me, the only meaningful distinction is e2e tests or unit tests, specifically, e2e tests are, say, examining requests and responses from JSON API server you're developing, and units tests are everything others.
If you need to mock, it’s not a unit test.
One of the best videos, @branvandermeer, indeed.