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

Decouple logic from business processes

If we have more complex business conditions, we can once again use Rules to keep that logic decoupled from the business process in a declarative way.

http://salaboy.com/2012/07/28/processes-rules-or-rules-processes-2x/

...unless we like working in spaghetti code...

Fundamental Goal of OOP

A fundamental goal of OO design is to place the behaviour (methods) as close to the data they operate on (attributes), so that changes are less likely to propagate across multiple classes.

http://www.codemanship.co.uk/parlezuml/metrics/OO%20Design%20Principles%20&%20Metrics.pdf

Big Ball of Mud and Intolerance of it

The following may be one of the most quoted paragraphs in software literature (my emphasis added):

A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.

http://www.laputan.org/mud/mud.html

MVC Model Is a ViewModel

Confirmation below that the "model" in the MVC world is not a place for business logic:

http://code.tutsplus.com/tutorials/how-to-write-code-that-embraces-change--net-29716

Our models should be "request models", i.e. dumb data objects used for passing information from MVC to the business logic. Optionally, I see no problem including input validation in the models, but nothing more. Business logic should not be in the models.

A Rule of Thumb for Cohesion

from http://code.tutsplus.com/tutorials/how-to-write-code-that-embraces-change--net-29716

You can think of ISP as a higher-level cohesion principle.
When both UI classes depended on the Broker interface, they were similar to two classes, each having four fields, of which two were used in a method and the other two in another method. The class would have not been very cohesive.

Getters/Setters is Fine-Grained Interface is good OOP?

Martin Fowler seems to agree with this notion by mentioning all three in the same breath in an article on the disadvantages of distributing objects.

from http://www.drdobbs.com/errant-architectures/184414966

A local interface is best as a fine-grained interface. Thus, if I have an address class, a good interface will have separate methods for getting the city, getting the state, setting the city, setting the state and so forth. A fine-grained interface is good because it follows the general OO principle of lots of little pieces that can be combined and overridden in various ways to extend the design into the future.