Nov. 21, 2015
Spent one hour to watch the video of topic: (Julia's rating A+) from 10:20am - 11:23am. Try to go outdoor to play tennis and get some workout in this freezing temperature. Come back later to get more notes written down, and help myself to continue to learn on this topic.
"Michael Feathers - the deep synergy between testability and good design"
https://www.youtube.com/watch?v=4cVZvoFGJTU
some notes: (Julia's comment, I made all the mistakes in the talk, that is the reason I like it; start to learn OO design)
1. video time 11:43/50:49
Solving Design Problems
Solving Testing Problems
solving design problems means solving testing problems.
Testing pain
State hidden in method
You find yourself wishing you could access local variables in tests.
Your method is so long.
Analysis for reasons:
Method are too long, SRP violations <- Julia's comment: agree!
More than 20 lines <- not good
usually 5 - 10 lines
matching human cognitive ability - small thing, focus on one thing, little thing
video time 14:36/50:49
Difficult setup
Instantiating a class involving instantiating 12 others
Need to factor the class into small pieces - you always can do that
Interface / Class / Object
too much coupling <- Julia's comment: made mistakes before, will be more careful!
concrete pain in the testing, but the problem is in the design.
video time: 17:25/ 50:49
Incomplete shutdown
Piece of your code lose resources and you never realize it until you test.
In detail, for example, you got to the shop, after the work, does not clean up after yourself; in C++, resource leak. In test environment, class should take itself better.
Classes Don't Take Care of themselves, Poor Encapsulation <- Julia's comment: still remember in C++ destructor, need to free the memory.
video time: 19:46/ 50:49
State-Leaks Across Tests
The state of one test affects another
For instance, share static mutable data through the tests. So, one test is depending on another test's actions.
Singletons or other forms of Global mutable state <- Julia: look into more later.
video time: 22:27/50:49
Framework frustration
Testing in the presence of a framework is hard
Insufficient domain separation <- Julia'a comment: watch again, example for domain separation.
video time: 24:39
Difficult mocking
You find yourself writing mocks for objects returned by other objects
Law of Demeter Violations <- Julia's comment: get more familiar with the law.
For example, A ->B->C->D, a chain of dependencies to get something.
Client code like A, B, C, D, those dependencies hurts you on compile time, also in conceptual, you have to know too many clients in order to do the piece of work. So, mocking is from fake A to fake B to fake C to fake D, real big pain.
video time: 26:58
Difficult Mocking - 2
Hard to mock particular classes
Answer:
Introduce interface <- Julia's comment: Good point!
video time: 28:07
Hidden effects:
You cannot test a class because you have no access to the ultimate effect of its execution.
Reason:
Insufficient separation of concerns, encapsulation violation
Hidden inputs - same type of things comparing to Hidden effects.
There is no way to instrument the setup conditions for a test through the API.
Reason:
Over-Encapsulation, insufficient separation of concerns.
video time: 30:31
Unwieldy parameter lists
It is too much work to call a method or instantiate a class
Reason:
Too many responsibilities in a class or method
video time: 32:07
Insufficient Access
You find yourself wishing you could test a private method.
Reason:
Too many responsibilities in a class
Test Thrash
Many unit tests changes whenever you change your code
Symptons: unit test always fails
reason:
Open / Close violations
In detail, Close for modification / Open for extension
class, function, need to have a small, tight focus, (Julia agrees, matching cognitive principles, small tight focus!)
small piece, easy to reason
Why?
small function, small test.
Good design follows cognitive principles. Small detail makes people easy to recognize.
The Golden Hammer <-
another name for dependency injection.
dependency injection
Groping Test Tools
Best example Julia's favorite:
a team many years ago, every class member/method is public; what is problem?
Should be a lot of things encapsulated, and a small API to access it.
Make tests too brittle.
using medical condition to help understand the OO design,
people do not feel the pain - easy to break bones, and others, can not live long
So, every one of us hates pain, but pain is the learning experience.
video time: 45:24
Testing isn't Hard. Testing is Easy in the Presence of Good Design.
Saturday evening video:
Escaping the Technical Debt Cycle - Michael Feathers
https://www.youtube.com/watch?v=7hL6g1aTGvo
Read the blog to understand Law of Demeter -
"Principle of least knowledge"
http://javarevisited.blogspot.ca/2014/05/law-of-demeter-example-in-java.html
http://javarevisited.blogspot.sg/2012/03/10-object-oriented-design-principles.html
Fast App Dev using Dependency Injection, Code First EF, and SOLID Design - SVNUG Presentation 32 (Julia comment: surprisingly great! good presentation, code with demo. Learn a lot!)
https://www.youtube.com/watch?v=zY1kzXPD568
