Study time - OO design, principles and testability

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