Python TDD Workflow - Unit Testing Code Example for Beginners 

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

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)

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.

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! :)

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. I'd recommend watching this talk by Ian Cooper, probably one of the best talks out there which goes over the common TDD misconceptions: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-EZ05e7EMOLM.html 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!

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

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

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

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.

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

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

Great introduction to unit testing. I really enjoy your content. Thanks.

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

Amazing! Thank you~~~ ✨

Very useful !!! Thank you so much !!! 🙂

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

Yet another great video👍

As always best video 😉❤️

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

Very nice tutorials, channel and a charming teacher . I recommend subscribing

good stuff, thanks Python Lady. I had a practice Python test earlier for a job, and another tomorrow. It has been so long that I could barely remember the syntax 😀

Wonderful!!!

Hey Mariya, what are those cool projections and lasers you have on you set-up?

Amazing 🤩

you are great teacher mariya

Excellent ❤

Could we spare the "if-else" and make it branchless with modulo?

Thanks a lot 👍

The wayscript link to the code no longer works. Is the code available somewhere else?

Today I enjoyed your videos on cryptography. But for security encryption techniques divide into symmetric and asymmetric encryption etc.

Hello, I love your videos about kivy)) I have a question: I will develop a mobile app and upload it to the Google Play. What do you think, can I use kivy or it is better to use java? Thank you)

Great 👍👍

22:19 If you keep copying your function code to the unittest section and back, isn't it to be expected that the output will be the same? I mean, you're basically testing if 2+2 equals 2+2 instead of 2+2=4. Wouldn't assertIsEqual(encrypt('banana'), 'cbobob') make more sense?

Hi teacher, I developed a small system in tkinter and it is fine without any error, my question is: How can i let it play a music when executing and closing? Thank you

One of the uses of testing is that we can get clarity of why things go wrong. To get clarity we want to watch out for tests that test too much at once. Too much (strictly speaking) is more than one real case at a time. If we test too much in the same case it becomes unclear why the test failed. In this example if we only tested a string that is made of all characters including characters not in the abc then we could fail because of a number of reasons. Maybe it was one of the characters not included in the abc variable (no clue which one), maybe it was because we hit an index out of bounds for the last character, maybe the characters do not map correctly, maybe it was because we're using a combination of abc included and non included characters (or maybe my pc just refuses to compute anything untill it gets some coffee). The point is that we don't get much of an idea why our test failed. Sure we can open a debugger and go though it but it is much nicer (as in quicker and less mindnumbing) if we can isolate the issue with a testcase since we can then quickly and clearly see what makes the issue occur.

15:15 hahaha love it!

Beauty with brains ;)

It looks like wayscript has shut down. Do you happen to know of any similar platforms? I'm only now hearing about it and it seems like a really cool idea.

what wallpaper you using at 1:06 if its any sort of wallpaper eninge please send me link and also what monitor do you use

great tutorial. anyway about 21:41, I just want to share a little cool trick. Instead of writing if else, you can just write it like this (it's applicable on any programming languange): abc[(abc.find(char) + 1) % len(abc)] for idx, char ... pretty cool right :)

pls can u conver the now built-in "tombllib" module? looks far prettier, simpler and more readable format than csv or json.

How can I work for a company by learning from your videos?

Hi, Where to get that live bachkgrounds?

She is so awesome

I enjoy it when I apply cryptography in real life for example internet of things IoTs security cybersecurity and block chain etc.

Hi iam a sub. How do you do these Thing is there any suggestion for book for python,ml,dl And data scince

Hello 👋👋👋 Please make a video on how to connect kivy with emulator to check how our apps look on mobile device

I prefer pytest due to its non-oop nature. It's much easier to understand without prior oop knowledge.

I landed a segfault! woohoo!

Flashbang warning at 4:14

why my first law return ok ?

Like your content , you always make it interesting! I didn't get to see your last vid till today, & so I don't know if you'll see this- or if ur into gaming or not, but I thought I'd mention a few programming type games u might like. (newest 2 oldest) {All are available on steam} Robo Co. (it's a robot building/coding game that lets you use actual python script in game to program / enhance your creations ;) Autonauts vs Piratebots Autonauts (Use Obj & code-block style programming to automate tasks for your robots to ultimately create an autmated metropolis for the human colonists) Nimbatus (design & build your own ships & ultimately create & program dromes to mine asteroids & planetoids autonamously) Factorio (More of a factory building/manufacturing game @ the outset but later you can program drones, train loading/unloading/delivery & tons of other stuff. I have seen some one program the equivelent of an A.I. to decide where to & how to, deconstruct their current base & rebuild it section by section in a new location while fending of enemy attacks without any human intervention.) Space Engineers (the oldest of these- it came out in 2013 has low system specs but still looks nice- & still has new content releases every few months. It could be considered as a cross between Lego Designer & No man's Sky, Eve Online & the X- Series ) It lets you build & program ships, space stations, make ammunition, weapon, mech, or cruiser class+ ship factories that u make fully automated right down to what info from what components, sensors etc get diverted to what in-game display screens, lights doors etc.& then ship them to stations or the frontline for other factions/players to buy) This one is currently on sale for 50% off all versions & DLC I picked up the Space Engineers Ultimate Edition ($34.44 w/tax) It includes: Space Engineers, Space Engineers - Deluxe, Space Engineers - Decorative Pack #1 & #2, Space Engineers - Style Pack, Space Engineers - Economy Deluxe, Space Engineers - Frostbite, Space Engineers - Sparks of the Future, Space Engineers - Wasteland, Space Engineers - Warfare 1, Space Engineers - Heavy Industry

chr(ord(char) + 1) would be much better ig

i found another youtuber that you would make a perfect couple with !!

I've been watching you for a few seconds and already fell in love ❤❤❤

Looking forward to more AI stuff....

Nice approach, but you do know you shouldn't write list comprehensions that are very complicated. You should respect PEP8 also.Beautiful is better than ugly.Explicit is better than implicit.Simple is better than complex.Complex is better than complicated. Flat is better than nested. Sparse is better than dense. And most important ....readability counts.

I hate TDD with a passion! I recognize how important it sounds, and blackbox testing is great, but in my opinion TDD leads to far more complicated sphagetti code cause your sole aim is to satisfy a test. Just take a look at the final code in this video. It takes a nice clean algorithm and makes it almost unreadable. Also, as others have pointed out, the implementation in this video has some issues. I would even go as far as to say that you never tested for the existence of the encrypt function, went straight to it's output, this breaking a TDD law (OK, this is a bit of an exaggeration, but so is my annoyance with TDD). Anyways, still a great video!

Sorry to say but that List Comprehension breaks my heart. It is way to long and has to much complexity. When you add too much complexity to a list comprehension the readability goes down significantly, so next time just use a normal for loop. Try to follow the PEP-8 or the Black standard. If you follow one of these standard the maximum line length is 79 for PEP-8 and 88 for Black.

You are so pretty

when a beautiful women tech you something it becomes v easy to understand thank you please mor videos

How often in real life do you have to deal with a problem that is as trivial as this one? Those are overused school cases and are completely agnostic to reality.

Definitely this does not apply to C++, your test app won't compile. The workflow requires much more work. At work we do not apply it.

I can sum up why I hate unittesting and tdd in one example. Guy comes to me with his code. He can't figure out why it keeps failing the test. So I check his code and there isn't an issue with the stuff we needed. So I look at the unit test. It was the test that was bugged he wrote. See the stupid part about unittesting is they forget the test itself is just more code that may need debugging. So what are you going to do write another test to make sure the unittests aren't bugged. Well maybe that code is bugged so you should write more stupid test to check it. TDD results in programs that can in some cases perform a function well but it doesn't work well when you are trying to develop software to do what someone wants or needs. It also just bloats adds way more work. 35 years I have never gotten a single thing useful out of it. So I never used it myself. I won't work for an employer that demands me to use it so never had to myself. But I've held other people over that time with their code like the example above and it has only been problematic never once useful. If you want to do testing do it at a system or functional level. Even I do that. Lets say I am writing a compiler. I won't test at minor levels of code like you are showing. I have base code I have used for decades I know works so unless there is a compiler or hardware issue there is no point testing it till the end. I'll write something on the level of the interpreter or assembler and test it. Or I've been working with game engines a lot in the last decade as well. You can break those into parts like graphics engine, physics engine, sound, resource manager and so on. I test at those levels. Just to be clear I hate bloated code I'm a minimalist and performance junkie. I like small code the less there is the better. Two reasons it will usually perform better secondly there is less to debug if there is an issue. I can get it done faster if you need a 3rd reason. Kent Beck tells why TDD worked for him. He says in a video he had trouble focusing on larger problems at once. He has anxiety issues and wanted a way to be confident in his code working. To bad he didn't realize his unit tests are also code and what if he wrote those wrong? I think while someone is in college just learning to program it could be helpful to some. I don't belief it should ever be used in a business or production environment. Most my programming has been in the industrial fields power plants nuclear, chemical plants, fabs, ... Not once in that time has my code been linked to a failure or incident. If it had it would have cost lives. So I wasn't worried at the end of the day like Kent Beck if my code worked I cared if I got someone killed or not.

Don't do anything without Copilot do not waste time.

Im sick and tired of windows.

The first test you wrote is NOT a unit test. It does not test anything, there is nothing under test, it's 100% totally and utterly pointless. You would have been better off obeying Rule.2 by putting pass() in the unit test.

Boycot windows. Its all BS.

красотка)

Enter your secret message: banana Enter your secret code: -100 output: 76i6i6 is this answer correct I don't know but this video help me solve so many problems

Prof You know I was having a hard time installing QT 5 on the iMac the other day 🥲

drive.google.com/file/d/1ocd9KNNO7QCPt2HjIpBO-5ULfI5-8oNj/view?usp=share_link I had to see if ChatGPT could solve this relatively simple algorithm. It went the ord() route, but it fails on negative shifts and shifts outside the length of Unicode (doesn't wrap). Its explanation is also wrong as it says non alphanumeric characters will not be shifted, but they are by the program. I've found something like "encrypted_message += abc[(abc.find(char) + shift) % len(abc)]" is concise and works nicely for positive shifts, negative shifts, and shifts larger than the set of characters you use (ie it wraps).