Python TDD Workflow - Unit Testing Code Example for Beginners

Показать описание

In this tutorial we will play the game of unit testing! 🎮🎮🎮
To do so - we will learn a brand new coding workflow, implementing a set of programming principles known as Test Driven Development.
I will introduce you to the Three Laws of TDD (also known as the Three Laws of Uncle Bob) and show how to write a piece of software unit by unit, test by test, 2 minutes at a time! ⏱️
The end result is not only a cool encryption algorithm known as Caesars Cipher - but also a series of unit tests that ensures its accuracy and reliability.
In the very end - I also have a 🏆 CHALLANGE 🏆 for you! So make sure you tune in at minute 23:10 to participate and practice your new set of skills! 💪

⭐ CLONE MY CODE ⭐
-----------------------------------------

Also, please feel free to revise it and reshare your versions with the world!
Quick instructions of how to do this via Wayscript at minute 23:50

🚀 JUPYTER SYNTAX 🚀
-----------------------------------------

📽️ RELATED TUTORIALS OF MINE 📽️
-----------------------------------------------------------------
⭐ Classes and OOP:
⭐ Inheritance and Private Class Members:
⭐ If __name__ == "__main__" for Python Developers:
⭐ List Comprehension:
⭐ Software Design and Development Exam Practice Stream:

⏰ TIMESTAMPS ⏰
-----------------------------------------
00:00 - Intro
01:19 - Three Laws of TDD
-----------------------------------------
TEST 1 - Test Data Exists
-----------------------------------------
02:07 - Basic syntax
03:59 - Jupyter Notebook syntax
04:30 - Assertion
06:28 - Production Code
07:32 - 2 minutes
-----------------------------------------
07:54 - Test Input Data Type
09:12 - Test Return Output
10:16 - Test Input and Output Length
11:45 - Test Input different from Output
14:28 - Test Output Data Type
15:46 - Test Caesars Cipher
20:40 - Test More Inputs
23:10 - Challenge for you!
23:50 - How to share your code via Wayscript
25:09 - Thanks for watching! :)

🤝 Connect with me 🤝
--------------------------------------
🔗 Github:
🔗 Discord:
🔗 LinkedIn:
🔗 Twitter:
🔗 Blog:

🎯 Sources 🎯
--------------------------------------
⭐ Python unittest Documentation:
⭐ Professionalism and Test-Driven Development by Robert C. Martin:

💳 Credits 💳
----------------------
⭐ Beautiful animated graphics by:
⭐ Beautiful icons by:

Python Simplified

Рекомендации по теме

Комментарии

Unit tests should never duplicate code or test inputs prior to the code running. The code should validate the input. The unit test should only test a known input vs. a known result, generally to highlight a corner case like the end of the alphabet in the Cesar Shift

jacobsoby

I'm pretty sure this video was coming from a good place and was intended to shed some light on often ommited topic of writing tests. The problem is that it ended up being very very wrong in displaying how to do TDD (which btw a lot of ppl do hence why a lot of them hate TDD). I'd suggest looking at BDD which is pretty much TDD renamed to help developers avoid the misunderstandings that are floating around.

So let me share a few things I've learned about tests after leaving uni (where they completely butchered that subject)

First -> never ever write tests that test your implementation EVER, this will put you on a treadmill of spewing test that mean nothing and will force you to rewrite all of them whenever you make any change to your code
Second -> dont test FUNCTIONS or CLASSES, test MODULES (and I dont mean module in how Python defines it but rather a module of our program) because the modules are actually the smallest UNITS we should be testing, anything smaller are just implementation details which can change over time so its pointless to write tests for them (since we would then need to change those tests), what should not change over time (or at least not frequently) is the INTERFACE of any given module so pretty much test WHAT the module is supposed to do not HOW it does it (aka treating the module as a blackbox)

So in this case let's say our module is the CEASAR_CODE which has 1 function in it's interface ENCRYPT and what we want it to do is to take message and number and then return message where all of the characters were shifted by given number. And here is where the power of TDD (or BDD) comes in since we force ourselves to write the tests upfront we first have to think through WHAT we want our code to do and we'll think about the HOW later. Once we know what we want the code to do we can write tests that will check if it actually does it.
1. given string "abc" and number 2 check if encrypt returns "cde" - important to always give concrete examples (luckily we dont yet have any logic to copy paste)
2. given string of len 5 check if encrypt returns a string of len 5
These are quite the obvious ones but when you sit for a bit you start asking more questions like
What should happen if the number is 1 -> should it be invalid input or just return the message as is
Is empty string a valid input or not?
What if the number given is negative?
Maybe I want to be able to pass in the alphabet?
What errors and when do I want it to raise (just the generic TypeError and ValueError or maybe some custom ones to better fit the problem)
All of that makes you create a pretty strict set of rules that you want your code to follow and you end up with a test suite that checks if the test you written actually does what you wanted it to do (and not just what you told it to do which as we now is usually quite different from what we wanted :P)

Which leads to the yet another part, once you have a suite like that it gives you confidence that those requirements you put in are safe, you can't brick your code during refactoring because the tests will tell you about it. And refactor you should, that's the last step of TDD which i feel was ommited here RED -> GREEN -> REFATOR (write failing test -> write minimal code to pass that test -> refactor that code)

funkenjoyer

I have been learning the principles of software engineering for last 5 months, now with this new concept that was recently introduced, I was having a hard time grasping it. your video shed a light on a lot of concepts. Thanks for taking the time to explain to newbies like me.

rugmaable

Best video on unittest ever, so beautifully explained. Thank you

anandsrikumar

Thanks Mariya. Great video, as always! I appreciate the step by step approach. Not only is it good for learning unit testing, but development as well! :)

davidpimental

I genuinely enjoyed your video on TDD and appreciate the depth you went into explaining each step. Your presentation style is quite engaging!
That being said I couldn't help to notice several mistakes, so I hope I can provide you with some useful feedback:
1. Some of the initial tests went green/passed but there wasn't ANY production code written, you just added some code on the test itself to make it pass, which violates the TDD laws, the code to make the test pass HAS to be production code. Also you want to make sure that your tests are against the module/unit you are trying to validate/design, in this case it doesn't make much sense to test the "input", you want to focus your test against the encrypt function.
2. The last test you wrote was very tightly coupled to the implementation details of the solution, it basically validated that "1 + 1" equals "1 + 1", sort of a tautology. As a matter of fact, in order to make the test pass you had to fix the production code AND then replicate the fix on the test, a bit of a red flag. Tests should be more like "validate the expected output is equal 2", so that you are free to implement it as "1 + 1" or "1.2 + 0.8" and then in the future change it to "0.5 + 0.5 + 1" (you get the idea), so the test is resistant to refactoring and not prescribing a specific implementation.
3. You had the right mindset from the outset, i.e. divide and conquer and proceed incrementally to build a solution, but then you sort of dropped the whole logic into the last test with no increments whatsoever, you should have split that test in many many cases: e.g. "shift letters by one", "deal with numbers also", "deal with spaces/other-chars" etc.
4. The 3 steps of the TDD cycle include a refactoring phase after the green phase (Red-Green-Refactor), and is a very important one, because that's were we can make the code more readable, clean, well-designed and what not, for instance the logic for the encryption function felt like a good candidate for refactoring. Just to be clear, refactoring can be applied to both production and test code.
5. You kept changing the single message "manually", but what you actually should have done is to codify those manual steps into test for those boundary conditions, so that they can catch regressions in case somebody (you included) modify the code in the future.

All in all, I really appreciated the effort, don't worry too much about the mistakes, we've all made the same mistakes throughout our own TDD learning journey, so keep practicing!

marco.garofalo

Thank you for this lesson on unit testing for beginners. It was very clear and comprehensive!

ojarikreegbenine

I'm so happy you did this video, helped a, just needed a unit test for my project
Thanks again for your lovely content 😊

ort

Love it! Excellent Tutorial. We now have snow in Ontario. I hope all is well. Play safe. :D

CurrentElectrical

I love your personality! You defo make learning python alot fun!

saami

Couple of decades as a deveoper under my belt and i have NEVER seen TDD actually applied in production. I meet lots of people who think it is a god idea, but nobody seems to actually use it, its hilarious.

richi

The first sentence of your video is a great analogy, well said.

tiamabderezai

Thanks for a video! It was handy for my project.:)

felex

Every video you make and I watch (they are amazing btw) it proves exactly how dumb I am

blevenzon

Please more QA tutorials, this is what I am missing from my toolbox

I've already mastered automation, now I need to learn things like TDD and BDD and son

CrazyFanaticMan