[Study Note] Design and Testability 20100417

为了整齐好看，文章的题目略有改动

Jeremy’s rules of TDD

1. Isolate the Ugly Stuff
2. Push, Don’t Pull
3. Test small before testing big
4. Avoid a long tail
5. Favor composition over inheritance
6. Go declarative whenever possible
7. Don’t treat testing code like a second class citizen
8. Isolate your unit tests, or suffer the consequences!
9. The unit tests will break someday
10. Unit tests shall be easy to setup

   0.  If code is hard to test, change it.

 

[Jeremy’s First Law of TDD: Isolate the ugly stuff]

1. Unit testing is only one layer of testing.
2. Automated unit tests are much, much simpler to write when you’re writing the tests upfront and purposely creating testability.

- Phil Haack, Unit Testing Loves Beta Testing And Vice Versa

Take the things that are truly difficult to test automatically and wrap them behind abstracted interfaces and separate any other code and functionality away from the difficult to test code.

doing TDD is learning how to divide the class responsibilities up in a way to make the code easier to test.

我也知道需要把那些“ugly stuff”独立出去，可是不知道应该如何做。最近开始使用 NHibernate，但是还需要更多的练习。

[Jeremy’s Second Law of TDD: Push, Don’t Pull]

Pushing gives you more control over a load, greater leverage, and it is safer and easier for your back.

1. Making unit tests easier to setup.
2. Greater chance of reusing code because of the shorter “taiil”.
3. Looser coupling because functionality is isolated from its configuration and/or data store

“I don’t care how good you think your design is. If I can’t walk in and write a test for an arbitrary method of yours in five minutes its not as good as you think it is, and whether you know it or not, you’re paying a price for it” – Michael Feathers, The Bar is Higher Now

Not what you think might happen, not what you hope might happen, but what it really does?

The dependency on the singleton can probably be eliminated and moved to an Observer pattern class that will also be injected into the translator class.

Dependency Injection

Builder Pattern

“Separate the construction of a complex objcect from its representation so that the same construction process can create different representations.”

 

 Builder Pattern 比较简单的例子就是：Shop(Director) + VehicleBuilder(Builder) + MotorCycleBuilder/CarBuilder/ScooterBuilder(ConcreteBuilder) + Vehicle(Product)，对我来说似乎和 Strategy patter 有些混淆。

Builder pattern is a simple and effective way to isolate logic from the mucky details of configuration and persistence.

The great advantage of using a Builder pattern is to isolate business logic a way from logistical code.

Configuration & Persistence Last

Advice give to people that are new to software design is to concentrate on creating functionality first, and worry about configuration second. Let the business functionality drive the need for configuration.