How to make code more testable, by factoring out and abstracting side effects

[@avalorthedoomed9594]

This is true art that leads to entropy. It makes me calm and inspired.

[@jlhjlh]

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).

[@sergiopietri5370]

bro is so chill it's almost relaxing to learn

[@Encysted]

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

[@StudyingWithAlex]

Totally intentional 😅

[@TJDeez]

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

[@MaakaSakuranbo]

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??"

[@albert21994]

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!

[@qualityedits3083]

wait, WHAT?? any CS degree should ABSOLUTELY cover this very, very thoroughly

[@albert21994]

@@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. 😂

[@haidaraji2415]

Great job. I think you excellently took the functional programming paradigm by separating pure function with impure function.

[@SyphriX]

This may be the best introduction to hexagonal architecture (or, more accurately, port-adapter architecture with simulators) I’ve ever seen

[@chritical_ep]

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!

[@mxc_clips]

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 😅

[@madjesc]

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

[@ivankudinov4153]

Your level of explanation, montage and overall atmosphere are genuinely beautiful. PS was so happy to see vim

[@kevinrobertandrews]

Oh man, those two rule of thumbs are really well thought out. Thanks for sharing!

[@nelsonthekinger]

Super well executed, thank you so much for your work. great summary on the subject 🙏

[@PatriceStoessel]

very nice explanation ! You could also mention "hexagonal architecture" or "port and adapters" architecture which generalizes this approach to the whole software system

[@anton-shubin-live]

Amazingly clear and simple description of a complex topic! Keep going, man! You are great! :)

[@riebeck1986]

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?

[@StudyingWithAlex]

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!

[@amirshabani1505]

What an amazing video. You deserve WAYYY more views.

[@BaptistPiano]

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!

[@lesih2362]

Thank you for such great content! I love your scenario. It is a very simple and to the point.

[@matrixtoogood5601]

Such an amazing explanation of these concepts, subscribed!

[@bassguitarbill]

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!

[@joesligo1516]

Excellent video!

[@markadell]

Keep doing videos like that! Thanks!

[@Nellak2011]

@Studying With Alex I love your style. Instant Sub.

[@dawid_dahl]

Perfect! Thank you so much.

[@WhiteSiroi]

thank you very much, very helpful

[@theodorealenas3171]

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.

[@abdulhamidalsalman]

great tutorial. you are the best on the web.

[@benmatt8940]

Outstanding! This is proof that coding is an art!

[@turner7777]

Quality content right here!

[@theflutterboi]

Thanks for video💙

[@frankie_goestohollywood]

Excellent!!!!! Thank you 🙂

[@TheKrazyKat89]

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.

[@eduardoalvarez4457]

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.

[@mehtubbhai9709]

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...

[@mauroprogramador4486]

Your VIM setup is very nice! Can you share it ?

[@blarvinius]

Very good. Would you do a video on "rejiggering vs refactoring" ? 🙂

[@cromatikap]

thank you sir

[@wayneleo9281]

Could you share your Vim configuration? It seems there are lots of useful features beyond the default version.

[@oxcafeoxbabe]

I think what you have done here is not necessarily dependency injection but inversion of control.

[@MrStealthWarrior]

Isn't testing for calls to writeFile and readFile is testing implementation details?

[@cn-ml]

7:35 "you can exchange the ink cartridge and replace it with another one if they have the same shape"... yeah, but not really.

[@saurabhkakar05]

Thanks for your video. Is there any book that you can recommend having similar concepts explained?

[@tizianrettig5509]

One clarification, side effects are all things a functions does that alter an invisible or external state.

[@melkiy582]

Зная английский язык плохо - я всё равно понял суть этого видео. Автор - хорош)) Мега полезный совет!

[@ponderatulify]

Ugh, what do you use to edit your videos? :D Very smooth work

[@ponderatulify]

Beautiful example by the way! Subscribed

[@StudyingWithAlex]

I use Adobe After Effects!

[@Test-dp1ib]

Great video but isn’t this more about dependency inversion (as in SOLID) than dependency injection or am I wrong ?

[@guesswho1829]

How can we get more videos from you ? 🙏

[@nilp0inter2]

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.

[@GamingMad101]

Great video! I think the ending may have duplicated itself in the edit.

[@StudyingWithAlex]

Whoops, good catch!

[@viniciusataidedealbuquerqu2837]

is this technique useful when we have jest mocks?

[@viniciusataidedealbuquerqu2837]

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

[@Dxpress_]

@@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);

[@SAsquirtle]

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

[@youtubeenjoyer1743]

In the end you are left with untested code - the real filesystem implementation. I guess it should be easy enough to monkey patch the standard library function calls to test them, but this does not apply to software written in real programming languages.

[@markcuello5]

Help me

[@scottamolinari]

rejigger? Did I hear that right? LOL! 😁😁

[@_general_error]

You put multiple test cases in one. Bad practice. But otherwise, you're using good metaphors... good job!

[@zizliyev8367]

AssertionError: excepted: count of outro to be equeal 1 :D sorry i have to do it

[@gago3001]

lol, i dont want my code to be testable for the tester to not ask me to code again, hahah!

[@vikingthedude]

My college software engineering course truly failed us

[@DurzoHighwind]

Typescript is hideous to look at.

[@indriq78]

what langs do you work with?

[@DurzoHighwind]

@@indriq78 C# Java

[@Dxpress_]

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.

[@R4ngeR4pidz]

"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?

[@darrorpsk6148]

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.

[@merukit]

I think it's intended to be 'unique words appearing more than once' so 2+ repetitions only adds one to the total count

[@alexmckay6387]

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.

[@itellyouforfree7238]

well i hope you don't work on any serious project then

[@PatriceStoessel]

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

[@PatriceStoessel]

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

[@alexmckay6387]

@@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.