Decompose and Expose

Large, complex private methods are a code smell. An implementation which is so complex that it cannot be usefully decomposed into component parts (with public interfaces) is a problem in testability that reveals potential design and architectural problems. The 1% of cases where the private code is huge will usually benefit from rework to decompose and expose. – S.Lott Feb 14 '12 at 20:06

http://softwareengineering.stackexchange.com/questions/135047/new-to-tdd-should-i-avoid-private-methods-now#comment253312_135049

Why not to use PowerMock

In my opionion [sic], creating a new collaborating service is not bad primarily because it's untestable, but because it introduces coupling and undermines polymorphism, and similarly for the static invocations of the Database class. 

 http://blog.xebia.com/mocking-the-unmockable-too-much-of-a-good-thing/

So "testability" has always been more than just whether a class is literally testable in terms of lack of technical limitations. Author seems to suggest "testability" has really been a proxy argument for good OOP design.

Having realized this, I now understand what Misko Hevery meant when he said the following (unfortunately without elaborating):

 Yes I am aware of them, and I think it is a bad idea. You are trying to compensate bad design with Monkey Patching.

http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/

Unit Testing: When You're not really Testing Your Logic

However if I am working on a PR for the winrm ruby gem that implements the winrm protocol or I am working on provisioning a VM or am leaning heavily on something that uses the windows registry, if I mock away all of these layers, I may fall into the trap where I am not really testing my logic.

If I mock everything out I may just end up testing that I am calling the correct API endpoints with the expected parameters. This can be useful to some extent but can quickly start to smell like the tests just repeat the implementation. 

Unit tests play the part of the compiler for interpreted languages:

If anything, unit tests that do no more than merely walk all possible code paths can protect code from randomly blowing up. 

http://www.hurryupandwait.io/blog/why-tdd-for-powershell-or-why-pester-or-why-unit-test-scripting-language

What not to Test in MVP

When unit testing MVP applications, the recommended practice seems to be you should test presenters and not views. Services fall into a similar "don't unit test" category because they'll need to connect to the server-side, which won't be running in a unit testing environment.

https://dzone.com/articles/building-gwt-applications-mvp

Don't test the model either as it's just a glorified bag of getters and setters.

Private Methods to Separate Classes

...if you have the urge to test a private method, the method shouldn't be private; if making the method public bothers you, chances are, it is because it is part of a separate reponsibility; it should be on another class." [Working Effectively With Legacy Code (2005) by M. Feathers]

quoted by 'blank' at http://stackoverflow.com/questions/7075938/making-a-private-method-public-to-unit-test-it-good-idea

What to Unit Test

Testing of a class should verify that: 1. methods and properties return expected values
2. Appropriate excepts are thrown when an invalid argument is supplied
3. Interactions between the class and other objects occur as expected when a given method is called

Crippledsmurf - http://stackoverflow.com/questions/62625/how-do-you-know-what-to-test-when-writing-unit-tests

Should you test internals (e.g. setting of private variables)? Some say no. On the other hand:

While it is true that there is a certain brittleness where test code knows internal details - this is unit testing, which is, by nature, whitebox, not black box.

http://googletesting.blogspot.com/2009/02/to-assert-or-not-to-assert.html - comment by Christian Gruber

Unit Testing Eases Design Process

... starting with unit testing is much easier when starting something from scratch.

http://coding.smashingmagazine.com/2012/06/27/introduction-to-javascript-unit-testing/