How to make code more testable, by factoring out and abstracting side effects
Вставка
- Опубліковано 15 чер 2024
- As a software engineer, sometimes the code you're trying to test accesses the filesystem, databases, other services, or the internet. But including them as part of the test makes tests slower, more brittle, and more expensive. I'll show you a best-practices way to factor out and abstract those pieces of your code so that it becomes easier to test, using our friends factoring, abstraction, and dependency injection.
Github repo with the code: github.com/aquach/studying-wi...
Blog post about how to decide what tests to write: blog.alexqua.ch/posts/how-to-...
Credits:
Raysonho @ Open Grid Scheduler / Grid Engine, CC0, via Wikimedia Commons
Rillke, CC BY-SA 3.0, via Wikimedia Commons
Amin, CC BY-SA 4.0, via Wikimedia Commons
00:00 Writing Some Code
02:46 Why Tests That Don't Touch The Filesystem Are Great
03:10 How To Refactor The Test To Not Touch The Filesystem
06:06 Intro To Abstraction
07:25 Abstraction In Everyday Life
07:46 Solving Our Problem With Abstraction
08:10 Coding The Abstraction Layer
10:26 Writing A Test Against The Abstraction Layer
12:11 Abstraction Recap
12:52 Testing Rules Of Thumb Recap
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).
bro is so chill it's almost relaxing to learn
This is true art that leads to entropy. It makes me calm and inspired.
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. 😂
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??"
Your level of explanation, montage and overall atmosphere are genuinely beautiful. PS was so happy to see vim
Super well executed, thank you so much for your work. great summary on the subject 🙏
Great job.
I think you excellently took the functional programming paradigm by separating pure function with impure function.
Amazingly clear and simple description of a complex topic! Keep going, man! You are great! :)
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!
Such an amazing explanation of these concepts, subscribed!
This may be the best introduction to hexagonal architecture (or, more accurately, port-adapter architecture with simulators) I’ve ever seen
Thank you for such great content! I love your scenario. It is a very simple and to the point.
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!
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!
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 😅
Oh man, those two rule of thumbs are really well thought out. Thanks for sharing!
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
very nice explanation !
You could also mention "hexagonal architecture" or "port and adapters" architecture which generalizes this approach to the whole software system
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 😅
What an amazing video. You deserve WAYYY more views.
Keep doing videos like that! Thanks!
great tutorial. you are the best on the web.
@Studying With Alex
I love your style. Instant Sub.
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!
thank you very much, very helpful
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.
Excellent video!
Perfect! Thank you so much.
Quality content right here!
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.
Thanks for video💙
Excellent!!!!! Thank you 🙂
Outstanding! This is proof that coding is an art!
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...
Very good. Would you do a video on "rejiggering vs refactoring" ? 🙂
thank you sir
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?
Great video but isn’t this more about dependency inversion (as in SOLID) than dependency injection or am I wrong ?
I think what you have done here is not necessarily dependency injection but inversion of control.
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.
Your VIM setup is very nice! Can you share it ?
Зная английский язык плохо - я всё равно понял суть этого видео. Автор - хорош))
Мега полезный совет!
Could you share your Vim configuration? It seems there are lots of useful features beyond the default version.
Isn't testing for calls to writeFile and readFile is testing implementation details?
Great video!
I think the ending may have duplicated itself in the edit.
Whoops, good catch!
7:35 "you can exchange the ink cartridge and replace it with another one if they have the same shape"... yeah, but not really.
How can we get more videos from you ? 🙏
One clarification, side effects are all things a functions does that alter an invisible or external state.
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
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);
You put multiple test cases in one. Bad practice. But otherwise, you're using good metaphors... good job!
rejigger? Did I hear that right? LOL! 😁😁
Help me
AssertionError: excepted: count of outro to be equeal 1
:D sorry i have to do it
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!
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.
"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
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.