POSSIBLE FUTURE BLOG POST TOPICS:

- Unit testing
	* Often causes object bloat. In order to test functionality, you often need to add some extra functionality. Rather than putting that into its own class, you just include it in the class so you can test it without adding a dependency.

- Unit testing at the wrong level of abstraction.
	* Developers create test fixtures per class. This is the wrong level of abstraction. A "unit" in unit testing is"the smallest testable part of an application". This is often thought of as the class, but can often be a single method. (http://en.wikipedia.org/wiki/Unit_testing)
	* A "test fixture" is a fixed state of the software under test used as a baseline for running tests; also known as a "test context". (http://en.wikipedia.org/wiki/Test_fixture)
	* Given this information, it may actually be a better abstraction to have a test fixture for each context that you want to test. This is not a new idea.
	* Results in more test fixtures (classes) but each one represents a separate context.
	* The converse is that very often context setup code ends up duplicated in many different test cases.

- Different aspects from Udi Dahan course.

- No best practices. Only "very good practices given a certain context."

- OOP programmers being scared of classes.

Add list of possible blog post ideas.
Add list of possible blog post ideas.
