Design Tech Talk Series Presents: OO Design for Testability

Google Tech Talk
October 6, 2009
ABSTRACT
Presented by Miško Hevery.
We design our code for performance, maintenance, simplicity, extensibility and other goals, but most of us do not think about testability as a design goal, yet verifying the correctness of our code is of great importance. What does it mean to have testable code, and what kind of trade offs does one have to think about when designing for testability. Turns out that testable code is well designed code, and it has many of the characteristics we search for such as low cohesion, separation of concerns, proper encapsulation and many others.

[@bugsthecat]

Ten years later now, the talk is still applicable industry-wide. Really good talk!

[@amiramhalperin]

This talk will remain applicable as long as humans will continue to code.
I enjoyed this talk when it just been published and I'm sharing it also today when teaching others.
Misko thanks for that. 🙌

[@amyh1112]

When I did code review and noticed that the code in the constructor is very hard to test. I requested it needs to be refactored. The engineer who submitted the pull request arguing with me saying that is the right way to have implementation in the constructor. So I googled "how to write testable code" to see how other people explain to write testable code better, and I found your blog and this video. Thank you for this awesome presentation!!

[@context177]

tried to write unit test to my ctor and I'm here too:)

[@Curelet]

Great talk that summarizes and brings new twists to the topics of Misko's previous 2 Google Clean Code talks "Global state and singletons" and "Don't look for things". Main ideas:
- Where to use the new keyword
- What should be done in the constructor
- Use of Global state and singletons is bad for testing due to side effects
- The use of Service Locator should be avoided
- Dependency Injection (DI) is the solution to the Law of Demeter violations.

[@neohubris]

Misko thank you very much for doing these talks. Your clean code talks has helped my work tremendously.

[@TankaNafaka]

I dint know how, now I know where to start. Thanks for sharing!

[@iosbfree1854]

Great talk. Great presenter. Great developer. Great ideas!
Thank you so much for sharing this!
❤🧡💛💙

[@elvedrano]

(long silence) "I forgot what this example was about... Let's just skip that!"
Priceless :D

[@bayantsinghkang67]

Makes me laugh even after 3 years.....

[@blackbindy]

@@bayantsinghkang67 and after another 3 years

[@phantruong1217]

and after another 3 years

[@vladimirvukanac]

This was really helpfull! This will be a "must see" for every code related person in my company.

[@christianb6718]

I've seen some videos from Miško Hevery. This helped me alot moving to the right direction.

[@sumitvyas13]

Awesome... For the 20 arguments problem the solution suggested is following SRP. Single Responsibility Principle takes care of simplifying the Object graph and code simplification.

[@skeom21]

Thanks...
I believe this is very helpful tip for all developers.

[@move1649]

Watched this 1st time 10 years ago, time flies

[@LucianoMoretti1]

Another Great Talk- a summary of his other "Clean Code Talks".
The one thing I still lament that is not addressed well is how to simplify DI and Testing in C++.

[@SaiGudigundla]

Thanks for the great presentation.

[@pereznels]

Awesome presentation!

[@yuskamify]

A very nice talk.. thanks.

[@espinchi]

Great talk!

[@lingyongwang2817]

this is great!

[@jalalsadeghi66]

this was very helpful

[@vaulttech]

I've searched for the other 3 talks (since this is the fourh) but I couldn't find them. Can someone please give me the link?

[@guilhermealveslopes]

Oh my, you can see how all these developers attending to the conference are shy as hell,
2021, still accurate

[@24sevenmtb]

Great talk!
Does anybody know where (if) the slides can be found online?

[@DotNetNukeVS]

You are so awesome

[@ErickDovale]

Very nice talk. A bit ambiguous with the term singleton. There is the singleton pattern as described in the Gof4 book which is the one that is problematic to test and there is the single instance of a class throughout the life of the application. There is nothing wrong with the latter IMO.

[@ericcartmansh]

at 23:04 wouldn't it make more sense to have the unit test create the Engine instance fakeEngine with getEngine() and pass in the engine factory and the model? Or is the call to getEngine assumed to be happening in the constructor of the Engine class?

[@2Guruda]

Google Car Drives itself. May be one day Google car will create its own Engine. :) Great lecture

[@HansVanIngelgom]

I also saw his previous "clean code talks" (it's been a while, so it was a good opportunity to refresh it), but am I wrong or did he change his mind about null objects? iirc, before he was a proponent of using null pointers.

[@BryonLape]

The problem is the corporate mind set.

[@uris77]

That is not the Law of Demeter. It is about types not dots.

[@leanJDe]

what is a friendly?

[@vishwajeetkakde1117]

A test double. Mocks, fakes, stubs, etc.