Here is a summary of the talk: -we can test at different levels -unit testing is testing at the class level -functional testing is testing at the "group of classes" level (you want to see if a group of classes work together properly) -scenario testing is testing at the "application" level (does the application behave correctly as a whole) -in order to unit test a class, that class must be isolateable (that way, if the test fails, you know exactly who's fault it was) -in order for a class to be isolateable, all of its dependencies must be passed in its constructor (the class itself must not "new" (create) any instances of the classes it depends on) -when testing a certain class, you can pass in stub objects, mock objects, or friendly objects to its constructor to satisfy its dependencies -whether you pass in stub, mock, or friendly objects, if the test fails, you KNOW its not b/c of the passed in dependencies, therefore it must be the fault of the object being tested -if you code so that your class gets all of its dependencies in its constructor, then you are doing "dependency injection" Hope this is helpful to someone :) Thank you to the presenter for such an informative and great presentation and thank you GoogleTechTalks for the upload! Very useful video!
Not just talks, after 3-4 years of this talk, he came up with AngularJS framework so that we can have Dependency Injection in JavaScript too, so that we don't have to rely on Monkey patching only. WoW. :)
For the subtitles where is says [INDISTINCT], 12:23 "tests that, that... that verify that the piston is the uh of the correct shape, that the oil is present," 30:30 "And genuinely, it's a lot less intrusive of a framework than a DI framework." 30:40 "Of course, Dave is the uh, the Ruby guy who's the highly-uh dynamic language guy, I'm the static type of guy." 31:00 "HEVERY: Aah, okay. So it keeps track of it and then cleans it up when it's done. OTHER (Same time): And it keeps track of everything, and restores everything when it's done. "
Practice TDD! I'm surprised TDD wasn't really brought up in this video. TDD more fully covers all of the topics discussed here (such as dependencies / decoupling / mocking / faking, unit testing, coverage etc). "Uncle Bob" (Robert C. Martin) has many good talks about how to practice TDD and the benefits of it here on RUclips. FYI, TDD will likely seam stupid at first - I thought so, but now I love it. And when practiced with S.O.L.I.D. principles and perhaps some good standard design patterns, it seems to encourage a good architecture too. You'll likely end up with a good Onion, Hexagonal, Ports & Adapters (whatever you want to call it) architecture.
I would still take his advice with a grain of salt. Some would say that you need end to end tests (not unit tests) to approve the project to ship (but maybe that was what he was talking about - idk - I've not watched this in a long time). Many would say that you don't ever expose internals even to tests. I would agree. Everything should still be encapsulated but without loosing coverage and while keeping the tests DAMP and simple. Doing this should help the design refactor into standard design patterns and SOLID principles (which is an acronym I believe Uncle Bob started). Achieving good encapsulation with perfect coverage of all logic/behavior should also help the design with cohesion as well and obviously decoupling the code at the same time.
Summary: How do you write hard to test code? 1. Mixing new with logic 2. Looking for things 3. Work in the constructor 4. Global state 5. Singletons 6. Static methods 7. Deep Inheritance 8. Too many conditionals 9. Mixing Service/Value 10. Mixing Concerns [It is difficult to test procedural code. Because in order to test we need to isolate something. In OOPS, this is done by polymorphism which is not present in procedural code.] [We are tied to the inheritance in run time and there is no flexibility. If we want to test class X, which inherits from other classes like A, B, C, D, E, F, G; it is hard to test X. We are also testing these other classes if we do that. No separation.] Writing testable code: 1. Good OO 2. Dependency Injection 3. Test-Driven Development 4. Knowledge about untestable code [There is no secret to writing tests but there is to writing testable code] Progression of Testing - Scenario/Large Tests - Tests the whole application by pretending to be a user - It can be a little slow and flaky - More execution time - Functional/Medium Tests - External dependencies are simulated - Tests collection of classes as subsystems - Medium execution time - Unit/Small Tests - Tests individual classes/methods in isolation - Very fast and doesn't normally need a debugger - Less execution time It is difficult to do unit testing of a class because class generally has dependencies and those classes have further dependencies. These intertwined networks of dependent classes make it difficult to test individual class. If it is a leave class, it is easy. But it is difficult to test a class slightly up the hierarchy. To do this we need to cut the dependencies or draw a line between the class and its dependencies. We could do this by many methods: - We can use the actual class that we trust that we have tested already that doesn't throw an error. - We can use a stub that may simulate the behaviour of existing code. - We can also mock the class. How can we separate these things or draw the line? We can separate Object Graph Construction & Lookup( i.e. constructing the application with all the instances of classes) from the Business logic. This makes testing easy. Practical example being: Rather than instantiating the dependent classes in the constructor of the class being put under test, pass the instantiated classes directly as arguments to the constructor. Now we are free to do this instantiation in the tests and pass it to the class being tested. If this is not done, we can't instantiate in isolation and in testing, we will be just mimicking the whole application. This would make unit testing scenario-based testing. Hence, the new operator should never be mixed with logic.
agree, a lot of literature covers topic, like "why procedural code is much easier to test". If you have a static method with big, unmockable side effects, than this code is bad by procedural standards. Pure procedural functions don't have side effects which is golden grail for testing.
Constructor paradigm: Ask for needed objects (by parameters) Do not instantiate dependencies. (Separating Object graph construction from business logic)
This should be part of some kind of "Google academy for software developers" A kind of virtual course for student with, and without, CS (or related) degrees.
Excellent, very insightful. I've been enjoying Misko's essays for a while now. However, in dynamic languages, I don't think it is true that static method calls cannot form a seam for testing. In Python, for example, a static method can be patched out temporarily on either the current module, or another module, for the duration of the test. We use this technique at my work all the time for testing.
"How do we write hard to test code? We mix object creation code with business logic. This will assure that a test (test case) can never construct a graph of objects (object graph - mocks, fakes, stubs, proxies) different from production. Hence nothing can be tested in isolation."
If tests are flaky, then there's probably a problem understanding the system. If the tests are slow, then there's probably a failure to leverage concurrency/parallelism. These two issues are not independent...
what can i take from this as a novice programmer who's still writing simple, single-script python programs? what habits should i start now to ensure i write my code to be testable as my programs get more advanced with experience?
when he mentioned about the evil of global state, i almost instatly thought of NWO.. :)) I think that's an analogy for the human anthropological level, and it's definitely untestable :P
+Kazathul why would you NOT want 100 % coverage of every single line of code, resulting in formal executable documentation, a drastic reduction in need for debugging and reducing the risk of refactoring to almost 0?
eNSWE Reduncancy and waste of time. Again, if we're programming an API it makes sense. Cuz then the end user will use every possible function in there so it's helpful. However for regular programs, I like to prepare test cases for the functionalities (top most hierarchy for the program) and white test all possible inputs and their results. Some functions I test the input before passing in to various functions. So if I unit test, they will fail. Where in the real program they never will. I hope I've explained well.
I'm sorry but it really sounds like you don't know what unit tests are and what the point of them is. not saying that to sound elitist or to bring you down, but you really missed the point. check out a book or two on the subject (try "the art of unit testing" by roy osherove or "test-driven design: by example" by kent becket).
Wow. This presenter talks as if this is all testing is, but hes missed out all of the investigative side of testing (e.g exploratory testing approach). I am dubious that this guy is even aware of the investigstive side of testing, since he's only talking about checking expectations so much... What about risks that you dont have an expectation for, therefore cant assert? You need to explore those risks. I hope the presenter learns about the whole picture of tesring soon, since hes presenting to a LOT of peaople to teach them... And only teaching them half of what testing is potentially really damaging.
Here is a summary of the talk:
-we can test at different levels
-unit testing is testing at the class level
-functional testing is testing at the "group of classes" level (you want to see if a group of classes work together properly)
-scenario testing is testing at the "application" level (does the application behave correctly as a whole)
-in order to unit test a class, that class must be isolateable (that way, if the test fails, you know exactly who's fault it was)
-in order for a class to be isolateable, all of its dependencies must be passed in its constructor (the class itself must not "new" (create) any instances of the classes it depends on)
-when testing a certain class, you can pass in stub objects, mock objects, or friendly objects to its constructor to satisfy its dependencies
-whether you pass in stub, mock, or friendly objects, if the test fails, you KNOW its not b/c of the passed in dependencies, therefore it must be the fault of the object being tested
-if you code so that your class gets all of its dependencies in its constructor, then you are doing "dependency injection"
Hope this is helpful to someone :)
Thank you to the presenter for such an informative and great presentation and thank you GoogleTechTalks for the upload!
Very useful video!
Concise and helpful. Thanks!
No problem :)
Thanks for the great summary!
Not a problem, glad you found it helpful! :)
Compact and essential. Thank you so much!
Watching this 8 years in the future. Still very helpful
Six months later... Still very helpful :-)
2 years later ;)
11 years later lol
Hi there from 2020
2023 here. Going to present this to our team tomorrow.
"Dependency Injection is asking for things in the constructor" I like that sentence
** "Dependency Injection is passing in ALL class dependencies through the constructor" **
Not just talks, after 3-4 years of this talk, he came up with AngularJS framework so that we can have Dependency Injection in JavaScript too, so that we don't have to rely on Monkey patching only. WoW. :)
This is a great talk from great programmer. I fully recommend it if you aren't familiar with the topic yet.
Speaker is the founder of Angular!! did you know?
For the subtitles where is says [INDISTINCT],
12:23 "tests that, that... that verify that the piston is the uh of the correct shape, that the oil is present,"
30:30 "And genuinely, it's a lot less intrusive of a framework than a DI framework."
30:40 "Of course, Dave is the uh, the Ruby guy who's the highly-uh dynamic language guy, I'm the static type of guy."
31:00 "HEVERY: Aah, okay. So it keeps track of it and then cleans it up when it's done. OTHER (Same time): And it keeps track of everything, and restores everything when it's done. "
Excellent talk. Very concise and intuitive examples.
Some great information. I like that you talk about things that aren't emphasized in school.
Excellent talk. Very concise and intuitive examples.....
great tut!
Practice TDD! I'm surprised TDD wasn't really brought up in this video. TDD more fully covers all of the topics discussed here (such as dependencies / decoupling / mocking / faking, unit testing, coverage etc). "Uncle Bob" (Robert C. Martin) has many good talks about how to practice TDD and the benefits of it here on RUclips. FYI, TDD will likely seam stupid at first - I thought so, but now I love it. And when practiced with S.O.L.I.D. principles and perhaps some good standard design patterns, it seems to encourage a good architecture too. You'll likely end up with a good Onion, Hexagonal, Ports & Adapters (whatever you want to call it) architecture.
I'm trying to find those videos where Uncle Bob talks about TDD practices, but I just can't find em, can you pass me URL ?
Thanks in advance
Thank you
+Stewart Anderson can u share the URL here ?
I would still take his advice with a grain of salt. Some would say that you need end to end tests (not unit tests) to approve the project to ship (but maybe that was what he was talking about - idk - I've not watched this in a long time). Many would say that you don't ever expose internals even to tests. I would agree. Everything should still be encapsulated but without loosing coverage and while keeping the tests DAMP and simple. Doing this should help the design refactor into standard design patterns and SOLID principles (which is an acronym I believe Uncle Bob started). Achieving good encapsulation with perfect coverage of all logic/behavior should also help the design with cohesion as well and obviously decoupling the code at the same time.
Excellent video... sums up the need for unit testing, dependency injection :)
back when I watched this first time, I thought testing a car was just an analogy
Summary:
How do you write hard to test code?
1. Mixing new with logic
2. Looking for things
3. Work in the constructor
4. Global state
5. Singletons
6. Static methods
7. Deep Inheritance
8. Too many conditionals
9. Mixing Service/Value
10. Mixing Concerns
[It is difficult to test procedural code. Because in order to test we need to isolate something. In OOPS, this is done by polymorphism which is not present in procedural code.]
[We are tied to the inheritance in run time and there is no flexibility. If we want to test class X, which inherits from other classes like A, B, C, D, E, F, G; it is hard to test X. We are also testing these other classes if we do that. No separation.]
Writing testable code:
1. Good OO
2. Dependency Injection
3. Test-Driven Development
4. Knowledge about untestable code
[There is no secret to writing tests but there is to writing testable code]
Progression of Testing
- Scenario/Large Tests
- Tests the whole application by pretending to be a user
- It can be a little slow and flaky
- More execution time
- Functional/Medium Tests
- External dependencies are simulated
- Tests collection of classes as subsystems
- Medium execution time
- Unit/Small Tests
- Tests individual classes/methods in isolation
- Very fast and doesn't normally need a debugger
- Less execution time
It is difficult to do unit testing of a class because class generally has dependencies and those classes have further dependencies. These intertwined networks of dependent classes make it difficult to test individual class.
If it is a leave class, it is easy. But it is difficult to test a class slightly up the hierarchy. To do this we need to cut the dependencies or draw a line between the class and its dependencies.
We could do this by many methods:
- We can use the actual class that we trust that we have tested already that doesn't throw an error.
- We can use a stub that may simulate the behaviour of existing code.
- We can also mock the class.
How can we separate these things or draw the line?
We can separate Object Graph Construction & Lookup( i.e. constructing the application with all the instances of classes) from the Business logic. This makes testing easy.
Practical example being: Rather than instantiating the dependent classes in the constructor of the class being put under test, pass the instantiated classes directly as arguments to the constructor. Now we are free to do this instantiation in the tests and pass it to the class being tested.
If this is not done, we can't instantiate in isolation and in testing, we will be just mimicking the whole application. This would make unit testing scenario-based testing. Hence, the new operator should never be mixed with logic.
agree, a lot of literature covers topic, like "why procedural code is much easier to test". If you have a static method with big, unmockable side effects, than this code is bad by procedural standards. Pure procedural functions don't have side effects which is golden grail for testing.
Constructor paradigm:
Ask for needed objects (by parameters)
Do not instantiate dependencies.
(Separating Object graph construction from business logic)
This should be part of some kind of "Google academy for software developers"
A kind of virtual course for student with, and without, CS (or related) degrees.
Great video!
Static’s are fine if they are purely utility or functional in nature so they don’t really hurt your tests.
The problem comes when they start referencing other dependencies
Clement Osei Tano correct.
What if I need them for performance reasons or to prevent memory usage/heap fragmentation (which can be troublesome on embedded hardware)?
can someone drop the timestamp for where he explains what a seam is?
19:27
Hello fellow 261 student
Aaron Segal lol hello there
@@promiseomiponle810 Hello last semester's 261 students lol
A good lecture on Testing :)
Keep the good Talks !
I am shocked that DI existed in 2008. I thought it was fairly recent stuff. 😅
Much appreciated
Excellent, very insightful. I've been enjoying Misko's essays for a while now.
However, in dynamic languages, I don't think it is true that static method calls cannot form a seam for testing. In Python, for example, a static method can be patched out temporarily on either the current module, or another module, for the duration of the test. We use this technique at my work all the time for testing.
"How do we write hard to test code? We mix object creation code with business logic. This will assure that a test (test case) can never construct a graph of objects (object graph - mocks, fakes, stubs, proxies) different from production. Hence nothing can be tested in isolation."
great talk!
If tests are flaky, then there's probably a problem understanding the system.
If the tests are slow, then there's probably a failure to leverage concurrency/parallelism.
These two issues are not independent...
check for conversation display.... unit testing
what can i take from this as a novice programmer who's still writing simple, single-script python programs? what habits should i start now to ensure i write my code to be testable as my programs get more advanced with experience?
Good
when he mentioned about the evil of global state, i almost instatly thought of NWO.. :))
I think that's an analogy for the human anthropological level, and it's definitely untestable :P
code quickly becomes hard to test if it is written .... _before_ the unit tests ;)
You have amazing English for an 1-year old.
5:54 Martin Odersky :)
+Dmitry Lambrianov how do you know?
It's good for every body #testervn
TIL about the word called monkey patch
many (complex) dependencies
More side effects
Post from shared Message.... !@# diff
Testing ...#qcvietnam
Ha ha! no audience!! poor lazy guys
I HATE unit testing.
Unless you're programming an API, I can't understand any reason why you'd do that....
+Kazathul why would you NOT want 100 % coverage of every single line of code, resulting in formal executable documentation, a drastic reduction in need for debugging and reducing the risk of refactoring to almost 0?
eNSWE Reduncancy and waste of time. Again, if we're programming an API it makes sense. Cuz then the end user will use every possible function in there so it's helpful.
However for regular programs, I like to prepare test cases for the functionalities (top most hierarchy for the program) and white test all possible inputs and their results. Some functions I test the input before passing in to various functions. So if I unit test, they will fail. Where in the real program they never will. I hope I've explained well.
I'm sorry but it really sounds like you don't know what unit tests are and what the point of them is. not saying that to sound elitist or to bring you down, but you really missed the point. check out a book or two on the subject (try "the art of unit testing" by roy osherove or "test-driven design: by example" by kent becket).
eNSWE I should check them out.
+eNSWE it's "test-driven development" by kent beck, awesome book
Wow. This presenter talks as if this is all testing is, but hes missed out all of the investigative side of testing (e.g exploratory testing approach). I am dubious that this guy is even aware of the investigstive side of testing, since he's only talking about checking expectations so much... What about risks that you dont have an expectation for, therefore cant assert? You need to explore those risks.
I hope the presenter learns about the whole picture of tesring soon, since hes presenting to a LOT of peaople to teach them... And only teaching them half of what testing is potentially really damaging.
Great talk!
good for programmers
the word deterministic is used. You do not comment on that.