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 ?
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!!
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.
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.
*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 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.
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...
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.
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.
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?
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.
@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.
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?
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.
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?
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.
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.
By far the best talk I've ever seen on testing
The 5 last minutes of this video are simply golden.
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.
Perfect video for those of us who are trying to apply JUnit first time in code without guidance
Incredible talk. Best use of my hour. The best in youtube... @Devoxx you guys are best.
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
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.
I loved everything about this talk
These days, I started writing unit tests and I find this video really really helpful.
Thanks a lot for your advices 👍👍
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
47:04 "Try thinking about the interface..." 👍
Thank you.
2022, I'm still learning from it
Come on man
Very helpful for a newcomer to unit tests
Amazing talk, I'm a PHP dev and still got a lot of useful information from this.
*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 talk, time to go back to my PHPUnit and change some things >_
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..!
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
Fantastic density of useful info
Test first doesn't neccesary hide implementation details. A lot of people do white box TDD, which leads invariably to coupled tests & brittleness.
I have one question: can you became my guru?))))
Thanks for great instructions.
Excellent presentation
Solid talk, very good info :)
great intro for TDD
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
great talk.
Nice presentation about unit test writing.
Very good, thank you.
Very helpful , Multithreading is always problematic.
Great video. Thanks for the info.
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.
Amazing talk. very informative.
Nice talk, thank you! :)
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.
great talk! congrats!
Great talk!
Where can I get SubmitQueue?
Cucumber is for acceptance tests not unit tests.
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.
Ok let me refactor my whole codebase so I can have "testing included in it".
Did he use the only port on his laptop?
Flakiness aka. Heisenbugs
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
hahahahah
Vokuhila tests passed
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?
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?
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?
I think random input is good.
The whole idea of him was to know all variations of randomness
"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
Most of the thing he said will not be possible in cloud computing environment like salesforce.
ConsciousMi Wrong.
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
1.5X thank me later
No!
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.