I fully agree on the first part. I partially agree on the second part, since creating an abstraction is a great way to achieve better testability. However, in that specific situation, I would much rather prefer creating a full end-to-end test instead of adding complexity in the form of unnecessary filesystem abstraction. There is nothing wrong with a test actually writing to the filesystem (use temporary locations, use containerization if necessary). That would actually be even better, because it test the entirety of the program (in the example given, there are still lines of code that aren't tested).
Maybe I'll send this to my team. I tried explaining we should break up the code to test it easier, but there was pushback around changing code to test it. I said TDD is literally all about writing code for tests. I lost the battle and now that's some of the only tests we've done. I push for ts, fail. I push for unit tests, fail. Ugh. I'll keep the dream alive. Anyway, this was a solid video
I know the pain. We don't do tests cause "there's no time for it". But then manual testing eats so much time and is prone to mistakes. And if something slips through the cracks it's "why doesn't this work, I thought you (manually) tested it??"
@@qualityedits3083 I am in my masters now. At my uni we had a mostly theoretical approach. It was expected you learn programming yourself on the side, because it takes up too much time. The exams and tests require you to code, little is about testing, because some professors themselves rarely have written something that needed to be. It’s the same university where Gauss, Hilbert, etc. has lectured and Oppenheimer got his PHD from. 😂
I started a new job recently, tried to run the "unit" tests, and they all failed because I hadn't started Redis, and the tests all wanted to talk to a real live Redis. I've got a lot of work ahead of me!
This was a really amazing video !!. It's' really amazing how organizing code this way makes it more so much easier to understand and test. Do you have any more resources for this?
Glad it was helpful! There are lots of resources on dependency injection. I have a few old blog posts on related subjects like composition over inheritance: blog.alexqua.ch/posts/design-objects-to-the-data/ and how to think about writing tests: blog.alexqua.ch/posts/how-to-think-about-writing-tests/ Hope that helps!
The doubled “Thanks for watching” clip at the end was a great touch to follow on the last section about catching accidentally doubled content from copy-pasting code lol
This video perfectly answers the questions I had. The techniques are described clearly and concisely. I've got to write this down. Thanks for the video!
Great video! I was hitting pain points and wasting time when writing tests for work on a project. Decided my knowledge about writing testable code was probably lacking and stumbled onto this video. Great explanation about these concepts. Saving this to use as a refresher when I start slipping again 😅
very nice explanation ! You could also mention "hexagonal architecture" or "port and adapters" architecture which generalizes this approach to the whole software system
Mocks are useful and this is a good introduction to them but this video should've touched on the pitfalls of implementing mocks. Taking the example of a filesystem mock, the one in this video will always read and write to files without issues. In the real world, your program may try to read from a file and find that it doesn't have read permissions. Your program may try to write to a file and find that there's no space left on disk. These are things that can happen but can't be tested for with a mock that simulates an ideal situation. A complete mock needs to emulate both working and non-working behavior.
i think it was just an example for keeping the video short. In deed in Test Driven Development, you start by writing the test first, in that case you will write those specific cases "hard drive does not have permission", "hard drive has not enough storage", etc. That will force you to read how to handle those errors in the real file system and create more mock FileSystemInterfaces for each mock scenario.
Props to you pal! I've been hitting my head to a wall thinking how to implement testing to some of my jobs code because they want me to implement testing, now that I've seen and get some ideas to how to implement the test of most of the source without bootstraping the whole kernel and database and passing all the api keys or trying to modify the http client services definitions at runtime with a mock object it's a bless that now I can at least imagine how to implement the tests
Thanks so much! Your channel is extremely helpful! I've figured out principle #1 on my own, but principle #2 came as such a pleasant surprise! I was saying "Man this guy is a genius" when it clicked. Lol. Keep up the great work!
I made a test keybinding for my latest school project. Saves compiles and "tests". If it's fast to test, you constantly test, and go from stable to stable. I never debugged so fast before! I got to try swappable interfaces. I didn't quite do that. Side note: not everything was sped up. In fact I missed the deadline he he! Woops.
Fantastic content!! The stuff that you cover I've not seen explained any better elsewhere. @Alex, are you still working on new content? I sure do hope so...
I agree with everything here except for the use of mocks. These are fragile and in general not that useful. Think about it, what you are really testing is that you wrote some line of code in the implementation. What you really want is to be sure that the side effects that are supposed to happen, happen. In my experience, when testing unpure code the only really useful tests are the ones that test the effects without picking in the implementation. Just wite a test that call readFile with a fixed file and check the result is the expected and writeFile writing something to /tmp. This is really noticeable with more complex side effects like databases. Mocking DB responses is a recipe for disaster.
amazing videos but man please use a better syntax highlighter or something, it's kinda painful to see all the gray text and make out methods/variables quickly
@@viniciusataidedealbuquerqu2837 You could always rewrite it to fit the arrange/act/assert pattern: // Arrange const input: string = 'a a'; const expectedResult: number = 1; // Act const actualResult: number = numRepeatedWords(input); // Asset expect(actualResult).to.be.eq(expectedResult);
"Compute number of words that show up more than once" By using a set, you won't save duplicates, so you can't register that a word is repeated more than once Unless I'm premature with this comment and this was an intended issue you left in?
That's the JavaScript part. TypeScript is a super-set of JavaScript that just adds static typing support. Makes it easier to work with, but it's more or less a bandage over an already finicky language.
i personally cannot see much point to this. mocking seems like a waste of time to me. i only bother testing complex pure functions and even then i usually just refactor into simpler, more readable functions.
As long as you work alone on small projects, it works. But when you need to work on projects too big to fit in your head, or when you work with other people who don't have your knowledge, successful tests protect you from regression when you have to modify the code
By the way, in my experience, the ideal granularity for a test is not function, it is *functionnality/use_case/user_story* It does not depend on the complexity or the simplicity : it has to focus of something valuable to the customer. So it is driven by functional aspect of the system, not by technical aspects
@@itellyouforfree7238 With all due respect, I do work on serious projects, I just have a different approach to you. I generally write a handful of E2E tests that test the most important sections of my application, which is usually interacting with a server or API. I make judicious use of services such as Sentry so that when an error does creep into my code I find about it (almost) instantly and can commit a fix. Unit tests increase my code base dramatically, and particularly when mocking is involved, and provide little confidence that all of the functions and routines I have written are working harmoniously together. Whilst E2E tests are 'expensive' and 'slow' when compared to unit tests, they do make me feel quite confident that the application is working correctly.
I fully agree on the first part. I partially agree on the second part, since creating an abstraction is a great way to achieve better testability. However, in that specific situation, I would much rather prefer creating a full end-to-end test instead of adding complexity in the form of unnecessary filesystem abstraction. There is nothing wrong with a test actually writing to the filesystem (use temporary locations, use containerization if necessary). That would actually be even better, because it test the entirety of the program (in the example given, there are still lines of code that aren't tested).
Maybe I'll send this to my team. I tried explaining we should break up the code to test it easier, but there was pushback around changing code to test it. I said TDD is literally all about writing code for tests. I lost the battle and now that's some of the only tests we've done. I push for ts, fail. I push for unit tests, fail. Ugh. I'll keep the dream alive.
Anyway, this was a solid video
I know the pain. We don't do tests cause "there's no time for it". But then manual testing eats so much time and is prone to mistakes. And if something slips through the cracks it's "why doesn't this work, I thought you (manually) tested it??"
This channel is a gem. I've majored in CS, and we never touched the topics you're talking about in your channel. Thank you for creating the content!
wait, WHAT?? any CS degree should ABSOLUTELY cover this very, very thoroughly
@@qualityedits3083 I am in my masters now. At my uni we had a mostly theoretical approach. It was expected you learn programming yourself on the side, because it takes up too much time.
The exams and tests require you to code, little is about testing, because some professors themselves rarely have written something that needed to be.
It’s the same university where Gauss, Hilbert, etc. has lectured and Oppenheimer got his PHD from. 😂
This is true art that leads to entropy. It makes me calm and inspired.
bro is so chill it's almost relaxing to learn
Great job.
I think you excellently took the functional programming paradigm by separating pure function with impure function.
I started a new job recently, tried to run the "unit" tests, and they all failed because I hadn't started Redis, and the tests all wanted to talk to a real live Redis. I've got a lot of work ahead of me!
This was a really amazing video !!. It's' really amazing how organizing code this way makes it more so much easier to understand and test. Do you have any more resources for this?
Glad it was helpful! There are lots of resources on dependency injection. I have a few old blog posts on related subjects like composition over inheritance: blog.alexqua.ch/posts/design-objects-to-the-data/ and how to think about writing tests: blog.alexqua.ch/posts/how-to-think-about-writing-tests/ Hope that helps!
The doubled “Thanks for watching” clip at the end was a great touch to follow on the last section about catching accidentally doubled content from copy-pasting code lol
Totally intentional 😅
Your level of explanation, montage and overall atmosphere are genuinely beautiful. PS was so happy to see vim
This may be the best introduction to hexagonal architecture (or, more accurately, port-adapter architecture with simulators) I’ve ever seen
This video perfectly answers the questions I had. The techniques are described clearly and concisely. I've got to write this down. Thanks for the video!
Great video! I was hitting pain points and wasting time when writing tests for work on a project. Decided my knowledge about writing testable code was probably lacking and stumbled onto this video.
Great explanation about these concepts. Saving this to use as a refresher when I start slipping again 😅
Super well executed, thank you so much for your work. great summary on the subject 🙏
very nice explanation !
You could also mention "hexagonal architecture" or "port and adapters" architecture which generalizes this approach to the whole software system
Mocks are useful and this is a good introduction to them but this video should've touched on the pitfalls of implementing mocks.
Taking the example of a filesystem mock, the one in this video will always read and write to files without issues.
In the real world, your program may try to read from a file and find that it doesn't have read permissions. Your program may try to write to a file and find that there's no space left on disk.
These are things that can happen but can't be tested for with a mock that simulates an ideal situation.
A complete mock needs to emulate both working and non-working behavior.
i think it was just an example for keeping the video short. In deed in Test Driven Development, you start by writing the test first, in that case you will write those specific cases "hard drive does not have permission", "hard drive has not enough storage", etc. That will force you to read how to handle those errors in the real file system and create more mock FileSystemInterfaces for each mock scenario.
Amazingly clear and simple description of a complex topic! Keep going, man! You are great! :)
Props to you pal! I've been hitting my head to a wall thinking how to implement testing to some of my jobs code because they want me to implement testing, now that I've seen and get some ideas to how to implement the test of most of the source without bootstraping the whole kernel and database and passing all the api keys or trying to modify the http client services definitions at runtime with a mock object it's a bless that now I can at least imagine how to implement the tests
Oh man, those two rule of thumbs are really well thought out. Thanks for sharing!
Thank you for such great content! I love your scenario. It is a very simple and to the point.
Thanks so much! Your channel is extremely helpful! I've figured out principle #1 on my own, but principle #2 came as such a pleasant surprise! I was saying "Man this guy is a genius" when it clicked. Lol. Keep up the great work!
Such an amazing explanation of these concepts, subscribed!
I made a test keybinding for my latest school project. Saves compiles and "tests".
If it's fast to test, you constantly test, and go from stable to stable. I never debugged so fast before!
I got to try swappable interfaces. I didn't quite do that.
Side note: not everything was sped up. In fact I missed the deadline he he! Woops.
Keep doing videos like that! Thanks!
Excellent video!
What an amazing video. You deserve WAYYY more views.
thank you very much, very helpful
Perfect! Thank you so much.
@Studying With Alex
I love your style. Instant Sub.
Thanks for video💙
Excellent!!!!! Thank you 🙂
I think what you have done here is not necessarily dependency injection but inversion of control.
Fantastic content!! The stuff that you cover I've not seen explained any better elsewhere.
@Alex, are you still working on new content? I sure do hope so...
7:35 "you can exchange the ink cartridge and replace it with another one if they have the same shape"... yeah, but not really.
Outstanding! This is proof that coding is an art!
Your VIM setup is very nice! Can you share it ?
thank you sir
great tutorial. you are the best on the web.
Зная английский язык плохо - я всё равно понял суть этого видео. Автор - хорош))
Мега полезный совет!
One clarification, side effects are all things a functions does that alter an invisible or external state.
Very good. Would you do a video on "rejiggering vs refactoring" ? 🙂
Quality content right here!
Could you share your Vim configuration? It seems there are lots of useful features beyond the default version.
I agree with everything here except for the use of mocks. These are fragile and in general not that useful. Think about it, what you are really testing is that you wrote some line of code in the implementation. What you really want is to be sure that the side effects that are supposed to happen, happen. In my experience, when testing unpure code the only really useful tests are the ones that test the effects without picking in the implementation. Just wite a test that call readFile with a fixed file and check the result is the expected and writeFile writing something to /tmp. This is really noticeable with more complex side effects like databases. Mocking DB responses is a recipe for disaster.
Great video but isn’t this more about dependency inversion (as in SOLID) than dependency injection or am I wrong ?
Isn't testing for calls to writeFile and readFile is testing implementation details?
Ugh, what do you use to edit your videos? :D Very smooth work
Beautiful example by the way! Subscribed
I use Adobe After Effects!
Thanks for your video. Is there any book that you can recommend having similar concepts explained?
amazing videos but man please use a better syntax highlighter or something, it's kinda painful to see all the gray text and make out methods/variables quickly
Great video!
I think the ending may have duplicated itself in the edit.
Whoops, good catch!
How can we get more videos from you ? 🙏
You put multiple test cases in one. Bad practice. But otherwise, you're using good metaphors... good job!
is this technique useful when we have jest mocks?
oh I dont know if I liked the expect in the fakemodule block. I think it breaks the create/act/expect rule, since it's on the beginning of the block
@@viniciusataidedealbuquerqu2837 You could always rewrite it to fit the arrange/act/assert pattern:
// Arrange
const input: string = 'a a';
const expectedResult: number = 1;
// Act
const actualResult: number = numRepeatedWords(input);
// Asset
expect(actualResult).to.be.eq(expectedResult);
rejigger? Did I hear that right? LOL! 😁😁
AssertionError: excepted: count of outro to be equeal 1
:D sorry i have to do it
Help me
My college software engineering course truly failed us
lol, i dont want my code to be testable for the tester to not ask me to code again, hahah!
"Compute number of words that show up more than once"
By using a set, you won't save duplicates, so you can't register that a word is repeated more than once
Unless I'm premature with this comment and this was an intended issue you left in?
He's using two empty sets, and adding items that reappear in the second set. So the second set only has items that were seen once before.
I think it's intended to be 'unique words appearing more than once' so 2+ repetitions only adds one to the total count
Typescript is hideous to look at.
what langs do you work with?
@@indriq78 C# Java
That's the JavaScript part.
TypeScript is a super-set of JavaScript that just adds static typing support. Makes it easier to work with, but it's more or less a bandage over an already finicky language.
i personally cannot see much point to this. mocking seems like a waste of time to me. i only bother testing complex pure functions and even then i usually just refactor into simpler, more readable functions.
well i hope you don't work on any serious project then
As long as you work alone on small projects, it works.
But when you need to work on projects too big to fit in your head, or when you work with other people who don't have your knowledge, successful tests protect you from regression when you have to modify the code
By the way, in my experience, the ideal granularity for a test is not function, it is *functionnality/use_case/user_story*
It does not depend on the complexity or the simplicity : it has to focus of something valuable to the customer.
So it is driven by functional aspect of the system, not by technical aspects
@@itellyouforfree7238 With all due respect, I do work on serious projects, I just have a different approach to you. I generally write a handful of E2E tests that test the most important sections of my application, which is usually interacting with a server or API. I make judicious use of services such as Sentry so that when an error does creep into my code I find about it (almost) instantly and can commit a fix. Unit tests increase my code base dramatically, and particularly when mocking is involved, and provide little confidence that all of the functions and routines I have written are working harmoniously together. Whilst E2E tests are 'expensive' and 'slow' when compared to unit tests, they do make me feel quite confident that the application is working correctly.