Effective Unit Testing by Eliotte Rusty Harold
Vložit
- čas přidán 18. 06. 2024
- Please subscribe to our CZcams channel @ bit.ly/devoxx-youtube
Like us on Facebook @ / devoxxcom
Follow us on Twitter @ / devoxx
You've been bitten by the testing bug, are thoroughly test infected. Excellent! You're undoubtedly producing more robust, less buggy software faster and at lower cost. Now it’s time to think about what makes unit tests even better. We’ll discuss flakiness, debuggability, reproducibility, speed, specificity, independence, timing, and other characteristics of effective unit tests. Examples will be in Java and JUnit, but the principles apply generally to all languages and test frameworks.
When not laboring in his secret identity of a mild-mannered software developer, Elliotte Rusty Harold lives in a secret mountaintop laboratory on a large island off the East Coast of the United States with his wife Beth and dog Thor. He’s an avid birder and insect photographer. His fiction has appeared in Alfred Hitchcock’s Mystery Magazine, Crossed Genres, Daily Science Fiction, and numerous anthologies. He’s also written over twenty non-fiction books for various publishers including Addison-Wesley, O'Reilly, Wiley, and Prentice Hall. His most recent books are Java Network Programming, 4th edition, and JavaMail API, both from O’Reilly. Find him as @elharo on Twitter or at www.elharo.com/blog/ - Věda a technologie
01:46 Why do we write unit tests?
04:28 The Fundamental Principle of Unit Testing
04:40 What is a unit test?
05:46 No.1- Eliminate everything that makes input and output unclear or contingent
09:37 No.2- Write Your Tests First! - Run the test first ! Couple with API
13:57 No.3 - Why Unit Tests?
16:20 No.4 - Unit also means Independent!
17:33 No.5 - Tests and Thread Safety
19:17 The Two least Known Facts of Unit Testing
19:23 Test don't share instance data (In JUnit) - may not set it in setup
20:46 You can have many test classes per model class
21:21 Speed of Tests
24:06 General Principle - Passing Tests should produce no output
25:39 General Principle - Failing Tests should produce clear ouput
27:16 Flakiness ( tests sometimes passes and sometimes fails)
31:46 System Skew (different kind of flakiness) - test couple with environments(OS, character set)
34:18 Another Conditional Logic in Tests
35:21 Debugging (addressing bugs by tests)
37:04 Refactoring (write tests by refactor something)
39:15 Development Practices
41:55 Final Thoughts
42:37 Question From audiences
42:38 The asset about writing test first
46:18 What do you think tools like cucumber ?
B"H" Thank you so much. It should slowly become standard for talks to do this ToC for videos.
Wow! I just got put in charge of starting to develop a test suite for my company's software with no previous experience with Unit Tests. I took some online courses, but this was the final piece of the puzzle for me to understand what Unit Tests are, their purpose, what to test, and how to design and write them. Extremely helpful!!
Need lots of practice until you could finally get it.
The 5 last minutes of this video are simply golden.
By far the best talk I've ever seen on testing
I feel like I wanna give tips to youtube recomendation algorythm. I was looking for a good info about test desing and found nothing I could like, and them this piece of gold comes up.
These days, I started writing unit tests and I find this video really really helpful.
Thanks a lot for your advices 👍👍
Nicely presented and insightful. Years ago I read networking and I/O programming in Java books written by Mr. Harold. Very well written and easy to understand.
Incredible talk. Best use of my hour. The best in youtube... @Devoxx you guys are best.
Perfect video for those of us who are trying to apply JUnit first time in code without guidance
Very helpful for a newcomer to unit tests
33:21 When his cough made me alert.
BTW a great video helped me to learn why unit testing is important for my code.
same
Great lecture! This is a great way to learn to think. All people who write code make mistakes, and it helps to have some sort of safeguard in place where, if you have to modify the behavior of your code down the line, you risk less of a chance of some unforeseen bug cropping up because you thought thoroughly about them when writing the initial unit tests. Very thorough justification for writing unit tests.
Awesome overview, thank you for sharing this..!
2022, I'm still learning from it
Come on man
I loved everything about this talk
Great video. Thanks for the info.
Solid talk, very good info :)
19:23 "Tests do not share instance data" is true for JUnit, but exactly the same code structure does cause problems in NUnit. In NUnit, fixture instance is shared by all test cases it contains, what makes running NUnit tests in parallel really fun. Also parallel tests are disabled by default, and when you switch from default to parallel and see all red, be ready to rewrite your fixtures and move instance data to... somewhere, because there's no nice equivalent of JUnit behavior. So beware when using instance data in your test aggregates in different frameworks, and don't forget to check documentation.
Amazing talk. very informative.
I write unit tests in Typescript for Angular and still found this very helpful.
If u don't mind, do u have a repo with unit tests that I can look to as a reference as I'm also starting on a unit testing in angular
Amazing talk, I'm a PHP dev and still got a lot of useful information from this.
Nice talk, thank you! :)
Excellent presentation
great talk! congrats!
Very good, thank you.
Nice presentation about unit test writing.
Fantastic density of useful info
Code Coverage is simply a metric of how good your developers are at hiding bad Unit Tests with lots of Mocks. Nothing more.
It’s very game-able without the understanding of the big picture and implementing the wrong metrics
No way to get around thinking
Great talk, time to go back to my PHPUnit and change some things >_
Great talk!
47:04 "Try thinking about the interface..." 👍
Thank you.
great talk.
Very helpful , Multithreading is always problematic.
Test first doesn't neccesary hide implementation details. A lot of people do white box TDD, which leads invariably to coupled tests & brittleness.
*Multiple assertions are OK!* People are confusing things: you want a given-when-then structure, rather than a given-when-then-when-then... And one assertion cannot always test everything. You still test one thing at a time, and I think JUnit has a way to report multiple assertion errors. If not, then it should. Because it just feels wrong otherwise.
I was on the fence, but I am now firmly on the side of one assertion per test. One assertion means there's only one thing I need to check when I see red. Ambiguity is an enemy.
NUnit allows you to add messages when an asset fails. As long as you do that, there's no guessing necessary
Frankly I'm shocked JUnit doesn't include that
@@ScottKorin JUnit often adds a "message" parameter to their assertion methods, but I still don't recommend them because JUnit has a hard-to-read assertion API for multiple reasons (Yoda style, which parameter is which?). AssertJ is a cleaner choice, and it also allows customizing error messages with "withFailMessage", but it shouldn't be a frequent choice in my opinion, because it makes the assertion slightly less readable (especially if you put all chains on the same line, i.e. it pretends to be fluent-style API but it breaks the flow), and AssertJ supports many specific assertions out of the box. Instead, you can also use "as" to name the subject, or you can implement a custom assertion if you miss a certain kind and want to use it often. There is one notable exception where JUnit does better: "assertAll", as opposed to "SoftAssertions.assertSoftly".
great intro for TDD
I have one question: can you became my guru?))))
Thanks for great instructions.
15:24 Some test frameworks have "expect().toBe(...)" which will not throw an exception when it fails, allowing you to test different statements in one test and see exactly which are correct and which are not. IMHO this is better than throwing exceptions on test assertion failure...
I love Jest
do i have to test private function？ if private functions have to be test，is it have to be as safe as public functions?? for me, I have handled the exception check in public functions, and I don't want to handle it again in private function., since I know it will never happen.
Where can I get SubmitQueue?
Does anyone have the slide for it?
use Rx[Net, Java, JS vs] for multithreading and for other cool stuff, testing is included in it.
Vokuhila tests passed
Did he use the only port on his laptop?
How do we test time based systems?
Never call the system clock from the model code. Make a wrapper clock interface. In production, use a implementation of the interface which calls the system clock. In the test code use a stub implementation of the clock wrapper interface which gives you the times that you need for each test case.
Flakiness aka. Heisenbugs
How can i have all test passed when i wrote all test first? I would not be able to commit to repository. Probably i didn t get the point completely :/. Or some tests should be turn off before getting to them ? I think that would be pretty risky :/.
You're misunderstanding TDD. You don't need to test everything first, you just write enough test code so that you get a failing test. Then you implement it, refactor it if needed, and then write your next test. And you still implement a new feature, just with tests written first. You can and would commit your thing once you got a meaningful portion of that feature done. A test alone is not meaningful work, and you want your code to be unit tested before commit anyway.
Read about tdd
Writing *failing* tests first is the essence of TDD.
@Peter Mortensen It is best demonstrated by uncle bob. The idea is start writing your tests, yes you will get compile time errors or not really the ide wont let you build. With that, you then will start to write skeleton methods which will obviously fail (but atleast run it). Then start writing some code to make the test pass and then add something more to the test and repeat.
@@SirWolf2018 so your brilliant idea is to set yourself up for failure?
Cucumber is for acceptance tests not unit tests.
He forget to write test for the hole in his shirt :D
There are no holes in his shirt...
Except the gigantic one on his left side
hahaha, you mean his left side, his right side and 2 in the back... right? Those are there on purpose. I guess you've never seen a shirt with heat holes in your life. What do they use in your country? tunics?
It's a feature, not a bug
lol :D
"It takes 20 minutes to run the tests"... Well, you can try to run them on my machine ;) It will take 1-2 ... years ... to just run them
I think random input is good.
The whole idea of him was to know all variations of randomness
I don't like his acceptance of how long a test suite can take to run. In my opinion the entire test suite should never take more than a second or two to run. Because I run it every time I build the code and if I even have time to put my hands together and twiddle my thumbs then something is seriously wrong.
Doesn't it depend on the size of your code base?
Most of the thing he said will not be possible in cloud computing environment like salesforce.
ConsciousMi Wrong.
About 6 minutes in where he starts talking about testing the .net square root function is where I start calling bullshit. The simple argument is this, you cannot test a subset of input values, assert they produce the correct output and then assume that all input values from the superset produce the correct output values. That is a fallacious argument called generalisation. It is where a property exhibited by one member of a set is assumed to be exhibited by _all_ members of the set. Like if you see one person with brown hair wearing spectacles and assume all people with brown hair wear spectacles. False! Now here lies the problem with all testing, the number of test cases is too large or infinite so it is impossible or infeasible to test every case. This means even if you have 100% code coverage you cannot guarantee to have found any of the existing faults.
He never said that. 90%+ code coverage just meins there is a good chance finding bugs for *relevant* cases before they got shipped to production.
That's why it's very important to think about the cases your tests should cover.
You're looking for Fuzz or Random testing. Not Unit testing. Ain't nothing wrong with the Unit test not covering ALL possible inputs. That's what we have Random and Fuzz testing for. Unit tests help you catch quite obvious bugs, and it's still really helpful.
Maybe you read Jim Coplien's paper? All of these "most unit testing is a waste" arguments are strong reasons for what ERH says at the beginning: write the test first, then the code. One at a time. Most problems solved. In your answer I didn't see you offer any solutions.
Despite knowing TDD and CI, I still picked up some insights and different povs from this talk. Hmmm, did you actually watch the video past 6 minutes?
1.5X thank me later
No!
I give this presentation content a 60% - almost a failing grade. He thinks he should write a book? Yeesh.
Tell us what has test done to you and don't lie
talk is bunch of unstructured insights easy and simple to find - not interesting
Testing is a big fat waste of time.
so you searched on youtube to find testing videos, just to comment that its a waste of time? People who think testing is a waste of time arent watching videos on effective unit testing. Your brain is wired funny.
@@OlliePage I didn't search for it, the YT alog presented it to me against my will in my feed. You do understand the way YT works, don't you? If not why are you on here wasting peoples' time?
how so?
Enjoy your bugs
It's like oh I must not know how to code. Let me write some code for the computer to judge me instead of just writing good code in the beginning. Testers are morons.