This Is Why You Suck At Unit Testing

In this video, I'm going to show you 4 common mistakes that software engineers make when it comes to unit testing. By understanding and avoiding these mistakes, you'll be on the road to success in your programming career!

Unit testing is one of the most important aspects of software development. It allows you to catch mistakes before they make it into your production code, and it can save you a lot of time and hassle down the road. In this video, I'm going to share with you some of the most common unit testing mistakes that software engineers make. By avoiding these mistakes, you'll be on your way to successful unit testing!

🚶‍♂️ FOLLOW ME 🚶‍♂️

*The above links are affiliate links.

#softwareengineer #programming #vlog

[geoffnelson]

Good takes, would love to see solid code examples that aren't contrived "shape" classes or reading a character string and making sure it isn't a number. That's what I'm always looking for on Youtube with coding. Good code that makes me think differently about how I implement/approach problems. :)

[CrookedCCez]

0:27 - testing the implementation and not the behaviour
2:00 - your tests never fail
3:20 - your tests aren't clear
6:25 - not running your tests as part of a build process

[ezekieloruven]

The biggest observation that got me to use TDD mostly is the realization that TDD is always what you are doing, just that if you don't have a formal test, your "test" is the object's use in your code itself. So if you find you need another object, there WILL be tests and an expected interface, just those tests are now embedded in your code, and you can only know it works with your specific code and specific situation, not in all conditions you will inevitably end up changing your code into.

Separated unit tests ensure your object works as expected in all conditions it should face, and having those tests make it so you can confidently optimize or enhance functionality without losing our breaking old functionality.

[armanmasangkay]

Nice video. I'm curious, do you write test first or test after in your day job?

[bjk]

How can you mock in a way that won’t break when you change internal implementation?

[nicoqueijo]

What about a scenario where the function that's being tested doesn't produce an output but does a side effect. Is it okay to use "verifys" there to ensure that when that function was called the code took a certain path in the function's logic?

[saritsotangkur]

Mocking is not bad. If you already have good unit tests for some functions, you will sometimes want to assert that those functions were called with certain parameters in the functions that call them. Otherwise you’d get a combinatorial explosion of cases you should test.

[real-cid-chan]

Interesting fact I have observed:
If you test your initial version of your function, it is guaranteed to not work (unless it is a trivial function, in which case, testing that function might be overkill). So test that initial version, (which fails), and then start fixing it.

P.S. by "initial" version of the function before you ever ran it ever.

[SaifurRahman]

How should we test functions that return void?

[khatdubell]

Writing code without tests is a foreign concept to me at this point.