btw Arjan just wanted to mention that I literally got a job offer with twice my current salary by remembering things from your videos in the technical interview. most probably wouldn't have gotten it without you. thanks so much for what you do!
This guy is literally the best I've seen on youtube. He talks real python, not just some framework. Even when he's doing FastAPI, a lot of the stuff is hardcore python. Keep u the good job my man
After 3 hours of pain googling and youtubing, finally only your video made it clear how to run test from "tests" folder and make import work. FINALLY! THANK YOU SO MUCH
Same here. I find it quite complicated to make import work correctly. I would like to ask, is it right I can't run test_line_item.py as separate file getting import error "No module named 'pay'? So far when I wanted to test my code I just run separate parts of it, but with import in siblings folders it's not possible.
I'm so glad you've made this video, even though I don't need it anymore. I got a bit annoyed that there were so many Unit Test introductions, but nothing about what to do if you already have existing code, especially if said code contains a state, because all introductions have a nice, pure (meaning the function only has input and output - no sideeffects like printing text or saving files), function, which simply doesn't reflect reality.
I've been programming for a while using Python, and I'd plateaued quite badly. Your videos are fantastic, and they're constantly teaching me something new. Thank you!
9:23 there are two functions called `test_order_total`. Python only sees the second one, and the first one doesn't run. This is a great example of how you can have 100% test coverage and still be missing tests! I have my vscode configured to run flake8 and mypy. I make this particular mistake all the time when writing tests, but I get a helpfully annoying red underline under the name of the first duplicated function name.
Nice timing! I'm currently doing something like an internship where one of the things I'll be doing is to help betterify code written by my supervisor. One of the first things I'm going to be doing will be to set up tests and automate the various "did you write it appropriately". His code is quite good in general, but he has no tests, and when I asked if he used PEP-8 or another styleguide ... the answer was "I try to make sure to keep consistent tabs". I might not be able to help make the code itself better/faster (don't know yet!), but i will for sure be able to help make sure it's easier to refactor it and show that it's *working as it should*
You're quickly becoming one of my favourite programming tutorial channels. TH-cam has so much content which, on one end is all beginner programming concepts, and at the other end it's all frameworks and fancy programming features. I think you fill that gap in between where we take basic programming features and compose them in ways that make software development scalable and maintainable.
Thank you, this is exactly the nightmare I have to deal with. Instead of payment processors it’s expensive computations on gigabytes of data that need to be tested. Sigh. Can’t wait for part 2
I learned all these techniques hard way and hours of hard work. I wish I had come across your channel before. If you are a python developer, you can’t appreciate Arjans content enough this content is literally the abstract of years of hard work.
Great one. Good point that you can realize where the code needs refactoring from writing unit tests. The tests that check raise value error can actually Raise it from different calls (one the init of the object and the other from the call of the method) so those tests are actually not unit and are not testing in the way they are intended.
phenomenal editing job. Thanks for creating this. All content, no fluff, right to the point, no hemming/hawing, quick pace but calm delivery. I tip my hat to y'all. Subscribed and liked. Thank you for a top tier tutorial.
Love your intermediate tutorials with examples + refactoring! Would love more TDD and software design patterns guides (for dummies + for non-dummies) as well as I can write code in a pretty straightforward manner but not so much with the mindset of a production setting with best practices. Also really nice setup :D
Thank you for this valuable content. I have watched nearly all of your videos because I like the way you explain things. I'll start leaving comments on your videos to help the TH-cam algorithm even more 🙂
Glad you like the content! And thanks for liking/commenting under the video. It’s indeed good to help the TH-cam algorithm, but I also find the feedback really helpful in improving the videos I post.
Honestly im so greatful for your videos. Im learning so much, enjoying my time and gertting alot of motivation to improve as a datascientist/developer. Thank you so much!!!! Youre awesome!
In my experience, old code that doesn't have tests is often nearly untestable. I recently rewrote a (very old) program that dealt with databases. The UI and the rest of the code are so interwoven that you can't even let it generate an SQL string without first creating a UI component that's responsible for it. That's why I didn't even bother with it. I just rewrote it from scratch.
I'd like to know more about your choice of pytest over unittest. Are there particular factors that lead to a preference, or is it just what's more familiar? I've been working on some projects that mix bits from both pytest and unittest, and it's kind of a mess but I don't know which one to go with. There's things that annoy me about both. :D
The monkeypatch example was particularly interesting. I've only used it some to test a method that called input function. However, I modified sys.stdin to place my input strings rather than replacing the input function. Is there a preferred method or are they considered relatively equal?
When writing code with pytest.raises, I recommend only putting the line that you expect to raise in the block, otherwise it might accidentally catch a failure that is happening elsewhere.
Awesome video, I really enjoyed it. It would be very interesting to see mocking applied to a database connection. I work with a 25 year old project in Perl, and a relatively younger Python code, and both have no tests at all. Both are inmense codebases and is usually seen as "imposible" to add unit testing to it. Everything is based on data stored in a mysql database, but I have no clue on how to even start testing when I have to mock so much data
Really great video! I love to see things about testing :) Wouldn't it be better to put only the line which raises an error into pytest.raises (like in try/catch) or why is all the code inside the block?
Thanks Nico! Yes, good point, it would be better to only put the line that actually raises the error in the with statement, as this focuses the error detection better.
Arjan, I always enjoy your videos. You really do a good job of pacing the complexity from simple to advanced that makes learning here so appealing. If I could request that you follow up these videos with a "how to write unit tests for existing python code using unittest and mock/patch" that would be great. my organization recently switched over from the simpler pytest to now using the more complex unittest lib as standard, and the abstractions for mock and mocked classes for testing really make it hard to grasp exactly whats going on sometimes. Great video anyways
I must say that I'm a little disappointed that he starts by understanding the code, and the method isn't a thousand lines long. That said I did learn a lot and I love this channel thank you for all the amazing content!!! Thanks for testing videos!! Please more!!!
I hope you bring Mock into the conversation! Easier to use than writing lambdas and mock functions. Mock(side_effect=inputs) would have been a simpler way to monkeypatch the input calls.
Mock is a class not well understood, I've had to teach other engineers about it many times. Well worth learning about if you're serious about writing test code! It's very powerful to use in conjunction with monkeypatch.
Hey, @Joshua That is indeed an interesting functionality. Do you have any material to share? I have been using patch and magicMock, but feels so unnatural. Every time I have to Google/read up on some examples again
Very interesting video, can't wait for part 2! You mentioned writing tests before the actual code. I wonder, how would this work for functions, that are computationally heavy, for example because they do some complex image processing, or perhaps create a 3D scene? How would you provide the correct result for the assertions? It's hard for me to imagine how this scenario would work. I'm only a beginner when it comes to programming, so I hope my question makes sense. :)
Hi Dávid, if a function performs a very complex task, you would normally split up the function into several smaller functions that you can then test separately. For parts of your application that produce a complex result like a rendered image, a GUI, etc, a common technique used is snapshot testing. You generate the correct complex representation once and indicate this is the correct ‘snapshot’. When you change things in the code or add new features, the snapshot test verifies that the resulting output is still the same (or if it’s supposed to be different, you generate a new snapshot).
2 ปีที่แล้ว
@@ArjanCodes Got it, thanks for the explanation Arjan!
Very good video - as always :-). Just one remark: If you don't want to have some tests suddenly fail on 1/1/2025, you probably want to use either something like the freezegun module or set the card info dynamically :-).
Excellent video, I've been following it for some time and it's adding a lot of knowledge to me. A video on how to apply Mocks in situations involving API requests and database connection would be interesting.
I hope the code quality of tests in part2 will be much better, for example many many cases in here should use fixtures to not repeat code or create classes itself inside every test.
Didn't know I could actually write a comment with the purchase 😅 I Just wanted to give you a huge shout-out! I've been learning and growing in my engineering career for some time now and your videos have been a fantastic resource for me! Thank you for sharing your incredible expertise!
Hi Arjan It is a minor thing, but in 16:22, why do you prefer to use [int(d) for d in card_nr] rather than, e.g., list(map(int, list(d)))? Are there any benefits to this? Thanks
Nice video, thanks. I do have a question, though: 14:17 I don't understand what "test_card_valid_date()" is actually testing, given that it has neither an assert statement nor a "with".
In this case it is testing whether an exception will be raised when calling the charge method. Since the date is valid, the method should not throw an exception. The test passes if it doesn't.
1. At 9:40, why did test_order.py have only 77%? I thought all tests/ folder files will be 100% since all tests will be run by default. Anyway is there any reason to be checking for 100% coverage in files under tests/? Intuitively I would only care about coverage of the files they are testing, and not coverage of the test script itself. 2. 14:20 def test_card_valid_date() contained no raises or assert. I thought every test would need one of these to communicate what is expected. Is this test function saying that if we can run without errors, then it passes? This feels wrong because even if it passes, it still doesn't clearly communicate the expected state, especially when there are many lines in the test function
Great video! I'm catching up with your videos, so maybe you've done that already, but it would be a nice follow up to show how to create the same payment processing system and its tests if we were writing it using TDD from scratch, probably using dependency injection for the input and the payment service and therefore not need to monkeypatch
Super interesting content. I have a question (open to anyone): I see that in testing with a "valid" card the expiry date is being hard coded. Would this not be a problem in the future, when the hard coded values become a "past date" and the tets are run again (and fail)? Thank you! PS (after watching part 2/2) My question is answered there!
You are quite old, but you are not ancient. You have adapted and conquered so many changes, that's very impressive. Beside that the information and the enterprise ready information is just on another level. I no longer believe that programming has an age limit, you are so skilled at teaching and so skilled at technically coding. FUCKING Brilliant.
Thanks for the video, wasn't aware of monkeypatch, looks much easier to use than the other patches available to pytest and unittests. Had just one remark, be careful with only checking the exception type, especially if the function being tested has multiple of the same exception types, you had 2x ValueError in the same function, but could've triggered the wrong if statement without knowing. I prefer to also check the actual error message within an assert, to make sure that I'm triggering the correct ValueError.
10:06 are you viewing the coverage report within vscode? I don't know how to do that - are you using a plugin? Actually getting to the coverage report is the biggest pain point in my current workflow.
When I press Cmd+Shift-P and type 'browser' I get an option to open a simple browser. I think this is a plugin, but as far as I can see it's installed by default.
At 9:49 both tests have the same name, so you only test the second function. You can see at 9:55 that only 2 tests run… My rule of thumb for naming tests, is to be as explicit as possible. I will write what the test passes as input and what is the expected output. Like so: `test_order_with_2_items_returns_correct_total`.
It also helps to add a docstring to explain the rationale behind a test: ``` def test_order_total_single_item(): "Total should match the amount of 1 item" ... def test_total_order_multiple_items(): "Total should be equal to the sum of every individual item" ``` In normal code these docstrings would be redundant, but in test code it pays off to write down what the test is meant to do because we're not going to write tests for the tests 😅
Pytest is easily my favourite testing framework! And my favourite feature are fixtures! So easy to create and you can do all sorts of cool things with them too, parametrize, etc... What I am still struggling with is to do true TDD. I most often find myself having to do some exploration before being able to think what the tests will look like. Any ideas for that?
I often start by thinking about the program flow and writing tests for the "intended flow" first. Then I think about what can go wrong and write tests for that. It's also important to remember that you can't test for every case, so do not feel too bad for missing something. Also, restricting per module helps a lot. Like in this video, the flow is "You have an item, order it, and get charged for the order.". So you first write a set of tests for the items, then the order, and finally the payment processor. When writing tests, the most essential part is not thinking of the implementation code but instead, "How would I interact with this object/function/...?". At least, those are my opinions/tips.
@@veni_vidi_victorian good tips, emphasis on the last part. Thinking about how you would interact with it is more important than the implementation, good tests should also be able to tell a story of how you interact with the code base
This is a great question and often asked. I would suggest exploring an idea completely separately (like for example in a Jupyter Notebook) and learning about API’s or error habdling, and then returning to TDD. There are many ways … 🖖
Can you please suggest what is the right way to put constants (like error msgs, log messages, other strings used)? What is the best practice to use constants in python : (1) a separate .py file for storing strings (2) Enums (3) Dictionary (4) Named Tuples (5) Data classes (6) anything else
Depending on the size of your growing project tests will help you keep your own code stable while growing and extending it. If your feature set is very volatile tests will feel like a burden and overhead.
Hi Arjan. As always, it was a great video! Thank you for it. I noticed there were 2 test functions with the same name "test_order_total()". Is it ok to do that when writing tests?
Hi Arjan, would be nice to know how to test very complex clases like the ones that usually appears in Deep Learning. For example, pytorch_lightning.LightningDataModule... things like the shape of tensors in several configurations, training loops, etc. I don't really know if it's worth to unit test somehow these kind of things. Currently, I'm placing asserts in my the code itself but not unit testing systematically, would be nice to know at least your point of view about this topic!
Excellent example software -- too often I see horrible example code when talking about testing (which leads me to conclusions I will not say). Question: what are your thoughts about starting with writing acceptance tests for brownfield projects?
I got my first software testing job were we use pytest to automate the API testing. I am thankful that youtube recommended your video because i would rather learn this than watch Netflix :D Thanks for putting this out for free 🙏🏽
how do i test functions that returns unknown data? like fetching from an api? or functions that do really complex calculations and you cannot know the result before running it?
Doesn't 100% (or near 100%) coverage mean you're testing every decision tree branch in your code? If you do that, every little change in your code requires also changing a bunch of tests along with it. When you really want to use tests to be able to refactor more easily, shouldn't you test *intent*? For example, test the output of one unit of work, so you can change the underlying implementation and have your test confirm that your new implementation still yields the same results?
Hey Arjan, love your videos :) any way you could comment on writing testable code for data science? I find it hard to write unit tests for, for example, the result of a more complex data processing function or the result of a training job.
Thanks! A general tip to write code that's easier to test: whenever you can, treat data as immutable. So: read data, process it to create new data, but don't directly modify the data. By keeping data immutable, your processing functions are going to be easier to test since they are going to be mostly pure functions. Hope that makes sense. It's an interesting topic, I might do a separate video about this.
💡 Get my FREE 7-step guide to help you consistently design great software: arjancodes.com/designguide.
btw Arjan just wanted to mention that I literally got a job offer with twice my current salary by remembering things from your videos in the technical interview. most probably wouldn't have gotten it without you. thanks so much for what you do!
That’s awesome, congratulations!
That basically means that you owe him 20 percent of that, right? :p
Grats on the job man!
Was that a course you took?
Well done and congratulations!!
That’s amazing. Congrats.
I ll be Frank, design patterns, unit tests for existing code. You are my mentor. And you put up videos which are useful in a production environment.
Thank you so much, glad you like the videos!
Hi Frank!
This guy is literally the best I've seen on youtube. He talks real python, not just some framework. Even when he's doing FastAPI, a lot of the stuff is hardcore python. Keep u the good job my man
After 3 hours of pain googling and youtubing, finally only your video made it clear how to run test from "tests" folder and make import work. FINALLY! THANK YOU SO MUCH
Glad it helped!
Same here. I find it quite complicated to make import work correctly. I would like to ask, is it right I can't run test_line_item.py as separate file getting import error "No module named 'pay'? So far when I wanted to test my code I just run separate parts of it, but with import in siblings folders it's not possible.
I'm so glad you've made this video, even though I don't need it anymore.
I got a bit annoyed that there were so many Unit Test introductions, but nothing about what to do if you already have existing code, especially if said code contains a state, because all introductions have a nice, pure (meaning the function only has input and output - no sideeffects like printing text or saving files), function, which simply doesn't reflect reality.
I've been programming for a while using Python, and I'd plateaued quite badly.
Your videos are fantastic, and they're constantly teaching me something new.
Thank you!
Thank you Chadd, glad you like the videos!
9:23 there are two functions called `test_order_total`. Python only sees the second one, and the first one doesn't run. This is a great example of how you can have 100% test coverage and still be missing tests!
I have my vscode configured to run flake8 and mypy. I make this particular mistake all the time when writing tests, but I get a helpfully annoying red underline under the name of the first duplicated function name.
Came here to report the same thing! Nice spot 👏
Actually pytest shows the coverage of 82% for `test_order.py`, which gives a hint. So it's not a 100% coverage.
Nice timing! I'm currently doing something like an internship where one of the things I'll be doing is to help betterify code written by my supervisor. One of the first things I'm going to be doing will be to set up tests and automate the various "did you write it appropriately".
His code is quite good in general, but he has no tests, and when I asked if he used PEP-8 or another styleguide ... the answer was "I try to make sure to keep consistent tabs".
I might not be able to help make the code itself better/faster (don't know yet!), but i will for sure be able to help make sure it's easier to refactor it and show that it's *working as it should*
You're quickly becoming one of my favourite programming tutorial channels. TH-cam has so much content which, on one end is all beginner programming concepts, and at the other end it's all frameworks and fancy programming features.
I think you fill that gap in between where we take basic programming features and compose them in ways that make software development scalable and maintainable.
Thank you, this is exactly the nightmare I have to deal with. Instead of payment processors it’s expensive computations on gigabytes of data that need to be tested. Sigh. Can’t wait for part 2
I learned all these techniques hard way and hours of hard work. I wish I had come across your channel before. If you are a python developer, you can’t appreciate Arjans content enough this content is literally the abstract of years of hard work.
Great one. Good point that you can realize where the code needs refactoring from writing unit tests. The tests that check raise value error can actually Raise it from different calls (one the init of the object and the other from the call of the method) so those tests are actually not unit and are not testing in the way they are intended.
When you know the content is going to be worth the watch, so you like the video even before you start watching. Vreeslik baie dankie.
you an mCoding are some of the most valuable resources I've seen on youtube in a looong time....
phenomenal editing job. Thanks for creating this. All content, no fluff, right to the point, no hemming/hawing, quick pace but calm delivery.
I tip my hat to y'all. Subscribed and liked. Thank you for a top tier tutorial.
Thank you so much for the kind words, Beau!
Love your intermediate tutorials with examples + refactoring! Would love more TDD and software design patterns guides (for dummies + for non-dummies) as well as I can write code in a pretty straightforward manner but not so much with the mindset of a production setting with best practices. Also really nice setup :D
Thank you for this valuable content. I have watched nearly all of your videos because I like the way you explain things. I'll start leaving comments on your videos to help the TH-cam algorithm even more 🙂
Glad you like the content! And thanks for liking/commenting under the video. It’s indeed good to help the TH-cam algorithm, but I also find the feedback really helpful in improving the videos I post.
Now we're all leveling up guys, great 👏🏻😊
Arjan, you always exceed the expectations. Thank you once more for the content. The quality of the tips and the video itself are amazing!
Honestly im so greatful for your videos.
Im learning so much, enjoying my time and gertting alot of motivation to improve as a datascientist/developer.
Thank you so much!!!!
Youre awesome!
I'm glad to hear the videos are helpful!
Best python content here on YT. Also really like that shirt you're wearing. I would like to know where I can get one if you don't mind.
Excited for the Part2!! Arjan please post it asap...
In my experience, old code that doesn't have tests is often nearly untestable. I recently rewrote a (very old) program that dealt with databases. The UI and the rest of the code are so interwoven that you can't even let it generate an SQL string without first creating a UI component that's responsible for it. That's why I didn't even bother with it. I just rewrote it from scratch.
Your videos are fantastic, and each time I am learning something new.
I'd like to know more about your choice of pytest over unittest. Are there particular factors that lead to a preference, or is it just what's more familiar? I've been working on some projects that mix bits from both pytest and unittest, and it's kind of a mess but I don't know which one to go with. There's things that annoy me about both. :D
The monkeypatch example was particularly interesting. I've only used it some to test a method that called input function. However, I modified sys.stdin to place my input strings rather than replacing the input function. Is there a preferred method or are they considered relatively equal?
When writing code with pytest.raises, I recommend only putting the line that you expect to raise in the block, otherwise it might accidentally catch a failure that is happening elsewhere.
Thank you Arjan, really glad that somehow TH-cam algorithms showed your channel) your content is very helpful! Nice
Thank you Jury, glad the content is helpful!
Long time watcher. This was the video i was waiting for. I'm learning how to do testing and didn't know where to start.
Awesome video, I really enjoyed it. It would be very interesting to see mocking applied to a database connection. I work with a 25 year old project in Perl, and a relatively younger Python code, and both have no tests at all. Both are inmense codebases and is usually seen as "imposible" to add unit testing to it. Everything is based on data stored in a mysql database, but I have no clue on how to even start testing when I have to mock so much data
I just started delving into unit testing this week, so this video came at a perfect time!! Thank you so much, looking forward for part 2 :)
Coming up on Friday 😉.
Really great video! I love to see things about testing :)
Wouldn't it be better to put only the line which raises an error into pytest.raises (like in try/catch) or why is all the code inside the block?
Thanks Nico! Yes, good point, it would be better to only put the line that actually raises the error in the with statement, as this focuses the error detection better.
Arjan, I always enjoy your videos. You really do a good job of pacing the complexity from simple to advanced that makes learning here so appealing. If I could request that you follow up these videos with a "how to write unit tests for existing python code using unittest and mock/patch" that would be great. my organization recently switched over from the simpler pytest to now using the more complex unittest lib as standard, and the abstractions for mock and mocked classes for testing really make it hard to grasp exactly whats going on sometimes. Great video anyways
Thanks!
I must say that I'm a little disappointed that he starts by understanding the code, and the method isn't a thousand lines long.
That said I did learn a lot and I love this channel thank you for all the amazing content!!! Thanks for testing videos!! Please more!!!
I swear you have a hidden video camera in my office. You keep making videos on exactly what I am working on.
My professor assigned us to make unit test without ever telling us what a unit test is. Thank you for teaching me. I regret paying for college now lol
I hope you bring Mock into the conversation! Easier to use than writing lambdas and mock functions. Mock(side_effect=inputs) would have been a simpler way to monkeypatch the input calls.
Mock is a class not well understood, I've had to teach other engineers about it many times. Well worth learning about if you're serious about writing test code! It's very powerful to use in conjunction with monkeypatch.
Hey, @Joshua
That is indeed an interesting functionality. Do you have any material to share?
I have been using patch and magicMock, but feels so unnatural.
Every time I have to Google/read up on some examples again
Thank you Excellent, Arjan!
You are welcome!
Very interesting video, can't wait for part 2!
You mentioned writing tests before the actual code. I wonder, how would this work for functions, that are computationally heavy, for example because they do some complex image processing, or perhaps create a 3D scene? How would you provide the correct result for the assertions? It's hard for me to imagine how this scenario would work.
I'm only a beginner when it comes to programming, so I hope my question makes sense. :)
Hi Dávid, if a function performs a very complex task, you would normally split up the function into several smaller functions that you can then test separately. For parts of your application that produce a complex result like a rendered image, a GUI, etc, a common technique used is snapshot testing. You generate the correct complex representation once and indicate this is the correct ‘snapshot’. When you change things in the code or add new features, the snapshot test verifies that the resulting output is still the same (or if it’s supposed to be different, you generate a new snapshot).
@@ArjanCodes Got it, thanks for the explanation Arjan!
Very good video - as always :-). Just one remark: If you don't want to have some tests suddenly fail on 1/1/2025, you probably want to use either something like the freezegun module or set the card info dynamically :-).
Hi Marc, I’ll address this issue in part 2 this Friday.
Arjan you are a true gem, hope to learn more about python from you! Keep it going!
Hey Samir thank you, and will do! 😉
What a great discovery your channel is! Thanks a lot for all videos you are doing, fabulous job! Many greetings from Ukraine 💛💙
Thank you, happy you’re enjoying the content!
Just in ...Thanks Arjan for picking up this topic.
#11 here. Can't wait until next week. Great video again!
Excellent video, I've been following it for some time and it's adding a lot of knowledge to me. A video on how to apply Mocks in situations involving API requests and database connection would be interesting.
Great suggestion Igor, Thank you!
This is a super mega important topic, thanks for the video! Test order total is defined twice, I think, so only one will be exercised
Also monekypatch is a rather exotic path. Why not mock.patch with side-effect for the 3 different return values?
This was super helpful! Thanks for sharing.
Glad the video was useful!
Thank you, Arjan, for your brilliant work and helping!
Thanks so much, glad it was helpful!
This is fantastic, eagerly waiting for the next video!!
I hope the code quality of tests in part2 will be much better, for example many many cases in here should use fixtures to not repeat code or create classes itself inside every test.
Yes - I’m covering fixtures in part 2.
I'd love to know where you got that cool geometric led lights behind you. Also, big fan of all your content!
You're a legend, Arjan 👍
Thanks!
Didn't know I could actually write a comment with the purchase 😅 I Just wanted to give you a huge shout-out! I've been learning and growing in my engineering career for some time now and your videos have been a fantastic resource for me! Thank you for sharing your incredible expertise!
Thank you so much! I'm happy to hear the videos are helpful to you!
Hi Arjan
It is a minor thing, but in 16:22, why do you prefer to use [int(d) for d in card_nr] rather than, e.g., list(map(int, list(d)))? Are there any benefits to this?
Thanks
Nice video, thanks. I do have a question, though:
14:17 I don't understand what "test_card_valid_date()" is actually testing, given that it has neither an assert statement nor a "with".
In this case it is testing whether an exception will be raised when calling the charge method. Since the date is valid, the method should not throw an exception. The test passes if it doesn't.
This tutorial is very complete, thanks man!
Found this to be simple and effective guide!!!
I'm glad to hear you enjoyed the video!
1. At 9:40, why did test_order.py have only 77%? I thought all tests/ folder files will be 100% since all tests will be run by default. Anyway is there any reason to be checking for 100% coverage in files under tests/? Intuitively I would only care about coverage of the files they are testing, and not coverage of the test script itself.
2. 14:20 def test_card_valid_date() contained no raises or assert. I thought every test would need one of these to communicate what is expected. Is this test function saying that if we can run without errors, then it passes? This feels wrong because even if it passes, it still doesn't clearly communicate the expected state, especially when there are many lines in the test function
Great videos mate. Always learning something new from them.
very informative ! , I hope you'll cover also the type checking with mypy
Great video! I'm catching up with your videos, so maybe you've done that already, but it would be a nice follow up to show how to create the same payment processing system and its tests if we were writing it using TDD from scratch, probably using dependency injection for the input and the payment service and therefore not need to monkeypatch
Thanks and love that suggestion!
Super interesting content. I have a question (open to anyone):
I see that in testing with a "valid" card the expiry date is being hard coded. Would this not be a problem in the future, when the hard coded values become a "past date" and the tets are run again (and fail)? Thank you!
PS (after watching part 2/2) My question is answered there!
Excellent tutorial.
Glad you liked it!
You are quite old, but you are not ancient. You have adapted and conquered so many changes, that's very impressive. Beside that the information and the enterprise ready information is just on another level. I no longer believe that programming has an age limit, you are so skilled at teaching and so skilled at technically coding. FUCKING Brilliant.
Thanks Arjan for this good video.
Glad you liked it!
Thanks Arjan, thisvideo was super util for me.
Glad to hear it was helpful!
etymology suggestion for monkey patch: 1) guerillia -> gorilla -> monkey; 2) monkeying about with code (en.wikipedia.org/wiki/Monkey_patch)
Thanks for the video, wasn't aware of monkeypatch, looks much easier to use than the other patches available to pytest and unittests.
Had just one remark, be careful with only checking the exception type, especially if the function being tested has multiple of the same exception types, you had 2x ValueError in the same function, but could've triggered the wrong if statement without knowing.
I prefer to also check the actual error message within an assert, to make sure that I'm triggering the correct ValueError.
That's a great reason to use custom exceptions, and create a different one for each fail case!
10:06 are you viewing the coverage report within vscode? I don't know how to do that - are you using a plugin? Actually getting to the coverage report is the biggest pain point in my current workflow.
You could open a browser window in VSCode and open the coverage html report there. Whenever you generate a new coverage report, refresh the page.
@@ArjanCodes Does that require a plugin?
When I press Cmd+Shift-P and type 'browser' I get an option to open a simple browser. I think this is a plugin, but as far as I can see it's installed by default.
Hey man - moved house and I need to redecorate. Where did you get that thing on your wall? I love it!
At 9:49 both tests have the same name, so you only test the second function.
You can see at 9:55 that only 2 tests run…
My rule of thumb for naming tests, is to be as explicit as possible. I will write what the test passes as input and what is the expected output.
Like so: `test_order_with_2_items_returns_correct_total`.
It also helps to add a docstring to explain the rationale behind a test:
```
def test_order_total_single_item():
"Total should match the amount of 1 item"
...
def test_total_order_multiple_items():
"Total should be equal to the sum of every individual item"
```
In normal code these docstrings would be redundant, but in test code it pays off to write down what the test is meant to do because we're not going to write tests for the tests 😅
Fantastic stuff!
Thanks, glad you liked it!
Thanks a lot! Very much helpful!
Glad you enjoyed the video :)
Pytest is easily my favourite testing framework! And my favourite feature are fixtures! So easy to create and you can do all sorts of cool things with them too, parametrize, etc... What I am still struggling with is to do true TDD. I most often find myself having to do some exploration before being able to think what the tests will look like. Any ideas for that?
I often start by thinking about the program flow and writing tests for the "intended flow" first. Then I think about what can go wrong and write tests for that. It's also important to remember that you can't test for every case, so do not feel too bad for missing something. Also, restricting per module helps a lot.
Like in this video, the flow is "You have an item, order it, and get charged for the order.". So you first write a set of tests for the items, then the order, and finally the payment processor.
When writing tests, the most essential part is not thinking of the implementation code but instead, "How would I interact with this object/function/...?".
At least, those are my opinions/tips.
@@veni_vidi_victorian good tips, emphasis on the last part. Thinking about how you would interact with it is more important than the implementation, good tests should also be able to tell a story of how you interact with the code base
This is a great question and often asked. I would suggest exploring an idea completely separately (like for example in a Jupyter Notebook) and learning about API’s or error habdling, and then returning to TDD. There are many ways … 🖖
Sir, You're a genius!
Thanks, happy you’re enjoying the content!
super useful video, thanks again
Awesome stuff man, as always!
Thank you!
These videos are great.
Thank you Jacob, glad you like them!
Can you please suggest what is the right way to put constants (like error msgs, log messages, other strings used)?
What is the best practice to use constants in python :
(1) a separate .py file for storing strings
(2) Enums
(3) Dictionary
(4) Named Tuples
(5) Data classes
(6) anything else
I'm not doing this professionally, so I really doubt I will do many tests... But knowing how to is nice
Depending on the size of your growing project tests will help you keep your own code stable while growing and extending it. If your feature set is very volatile tests will feel like a burden and overhead.
Amazing I love it, thanks for doing what u do
Great video!
Thanks!
It seems that monkeypatch is even more powerful than Java's mockito in some aspects. Nice video.
Will the branch coverage (additional to line coverage) be in part 2?
Can the coverage metric also be shown directly in the editor?
Hi Arjan. As always, it was a great video! Thank you for it. I noticed there were 2 test functions with the same name "test_order_total()". Is it ok to do that when writing tests?
No, it's not OK. It's a bug caused by copy-paste, and it prevents one of the tests from running.
great video thanks!
Hi Arjan, would be nice to know how to test very complex clases like the ones that usually appears in Deep Learning. For example, pytorch_lightning.LightningDataModule... things like the shape of tensors in several configurations, training loops, etc. I don't really know if it's worth to unit test somehow these kind of things. Currently, I'm placing asserts in my the code itself but not unit testing systematically, would be nice to know at least your point of view about this topic!
Hello thanks for this video really helped... but is it possible to do a real payout system tutorial with stripe putting all these tests together ?
Excellent example software -- too often I see horrible example code when talking about testing (which leads me to conclusions I will not say). Question: what are your thoughts about starting with writing acceptance tests for brownfield projects?
You're all dressed up these days. I need hacker hoodie back once in a while
great videos - but your github does not have the before/after of the test modules. Could you share the link to them please?
I got my first software testing job were we use pytest to automate the API testing.
I am thankful that youtube recommended your video because i would rather learn this than watch Netflix :D
Thanks for putting this out for free 🙏🏽
Glad to hear it’s helpful!
how do i test functions that returns unknown data? like fetching from an api? or functions that do really complex calculations and you cannot know the result before running it?
Mocking for non-deterministic responses or validating the HTTP response code
Hello Arjan, how does it look like if you've used "unittest" built-in lib? And why do you prefer pytest? Thnks
Doesn't 100% (or near 100%) coverage mean you're testing every decision tree branch in your code?
If you do that, every little change in your code requires also changing a bunch of tests along with it.
When you really want to use tests to be able to refactor more easily, shouldn't you test *intent*?
For example, test the output of one unit of work, so you can change the underlying implementation and have your test confirm that your new implementation still yields the same results?
Hey Arjan, love your videos :) any way you could comment on writing testable code for data science? I find it hard to write unit tests for, for example, the result of a more complex data processing function or the result of a training job.
Thanks! A general tip to write code that's easier to test: whenever you can, treat data as immutable. So: read data, process it to create new data, but don't directly modify the data. By keeping data immutable, your processing functions are going to be easier to test since they are going to be mostly pure functions. Hope that makes sense. It's an interesting topic, I might do a separate video about this.
When should I use assert vs self.assertEqual?
Excellent breakdown! I want to try it out but I can't for the life of me figure out how to import "pay" from within "tests". How does this work??
really good video. thx!
Thanks, glad you liked it!