1. Terminology
   1. Unit test
   2. Integration test
   3. System test / functional test
   4. Regression test
   5. Continuous integration
   6. Diff
2. What
   1. ..tests if individual units of source code are fit for use
   2. Advantage
   3. Should be
      1. Small/Be fast
      2. Trustworthiness
      3. Specific
      4. Consistent
      5. Fully automated
         1. Only two possible results: Pass or Fail
         2. No partially successful tests
         3. A test fails -> The whole suite fails
         4. Broken window effect
      6. Single responsibility
      7. Tests isolation
      8. Environment isolation
         1. Under unit testing: It doesn't work!
            1. DB
            2. Time
            3. Web service
         2. Solution: Use fake
            1. Fast
            2. Easy to write
            3. Easy to re-use
            4. No test logic in production code
      9. Self-descriptive
   4. Code coverage
   5. UT Framework
      1. NUnit
      2. MbUnit
      3. MS Unit
3. Why
   1. Why have unit tests?
      1. Find bugs early / fast feedback
      2. Increase QA
      3. Make architecture better
      4. CostOfWritingUnitTests < Sum(BugFixing)
      5. 测试代码是功能代码的一个用户，考验系统可扩展性
      6. 有助于为每个class定义需求
      7. 详尽的测试套件（test suite）是强大而重要的文档
      8. 有效的回归测试
      9. 使重构变得有保障
   2. Why not
      1. Increases development time
      2. 现在架构不方便作UT
      3. 知识体系达不到
      4. 迫于项目进度要求
4. How
   1. Web UI
      1. Selenium
   2. Business Logic
      1. Unit tests
   3. Looks like
      1. Arrange
      2. Act
      3. Assert
      4. +2
         1. Set up
         2. Tear down
   4. 提高可测试性的技巧
      1. 针对接口编程，而非针对类编程
      2. 使用Strategy模式
      3. 迪米特法则：对象只应该调用自己触手可及的对象。
      4. 确保每个对象有合理的责任集
      5. IoC
      6. AOP
5. Fake
   1. When need?
      1. 真实对象不存在或不完备
      2. 真实对象本身不确定
      3. 数据源不稳定
      4. 代码依赖
   2. Stub
   3. Mock
   4. Mock Framework
      1. Moq
      2. Rnial
      3. Mols
      4. Advanced
         1. 可以用简单易行的方法定义模拟对象，无需破坏本来的代码结构表
         2. 可以定义对象之间的交互，从而增强测试的稳定性
         3. 可以集成到测试框架
         4. 易扩充
   5. Connection and distinction
6. Best practices
   1. 观念：除了可运行的代码，测试套件比其他任何东西都重要 小步前进：反对一次性编写一大堆测试套件；应测试一点，实现一点。 首先编写独立于代码的测试 在修正某个bug前，先编写一个单元测试，来表现这个bug 即使编写依赖于J2EE API的代码，也应确保它能脱离应用服务器进行单元测试。
   2. 把任何代码提交到CVS前，完整的运行测试套件 测试的名字要有意义 不要依赖于测试用例的先后顺序 如果用到了配置文件，从classpath来加载。 在IDE中运行单独的测试。 编写ANT脚本来运行所有测试，以及进行测试覆盖率分析
   3. 使用模仿对象来避免对外部资源的依赖 在必要的时候重构测试代码。 未实现的方法，让其抛出异常。 每个测试（JUNIT测试方法）只测试一件事情。 要保证测试代码的简单性，如果测试代码本身就很复杂，就会导致测试代码本身可能也有Defect。 另一方面，如果测试代码很复杂，往往说明被测试代码的设计不合理，接口不清晰，需要重新设计或是Refactory。
7. Reference
   1. The Art of Unit Testing with Roy Osherove
   2. Pragmatic.Bookshelf.Pragmatic.Unit.Testing.in.C.Sharp.with.NUnit.2nd.Edition.Aug.2007
   3. Manning - The.Art.of.Unit.Testing.with.Examples.in.dot.NET.Jun.2009
   4. Fowler Martin. "Mocks aren't Stubs"