The document discusses test-driven development (TDD) and design-driven development (DDD). It advocates for writing tests before code using short iterative development cycles. TDD helps produce clean code that fulfills requirements by making developers think about required behavior, providing documentation, and improving quality. Common objections to TDD are addressed, noting that it forces understanding of code and tests, creates reusable modular code, and drives simplicity. Guidelines for effective TDD include writing small focused tests with descriptive intentions that are independent and repeatable.

2. Email (samnang.chhun@gmail.com)
Blog (http://tech.wowkhmer.com)
Rails Developer
.NET Developer

5. About Testing!
Test Last or DDD (Design Driven Tests)

6. Short development iterations
Is a design process
Based on requirement and pre-written test
cases
Tests are your first users
The goal is to produce working clean code that
fulfills requirements
If TDD hurts then you're doing it wrong

7. Unnecessary Codes
Unchangeable Codes
Unintelligible Code

8. Makes you think about required behavior.
Provides documentation.
Improves quality.
Reduces speculative code.
Less time debugging.
Confidence in change
Discover usability issues early

9. I don’t have time to unit test.
The client pays me to develop code, not write
unit test.
I am supporting a legacy application without
unit tests.
QA and User Acceptance Testing is far more
effective in finding bugs.
I don’t know how to unit test, or I don’t know
how to write good unit tests.

10. It forces you to really understand the code.
It forces you to really understand the tests
It forces you to create code that is truly reusable
and modular and testable
These forces drive you to keep your code and
your tests simple and easy to understand.

11. Enabling TDD
TDD Cycle
Choosing the First Test?
Green Bar Patterns
State-based vs. Interaction-based Unit Testing

12. NUnit Resharper
MbUnit TDD.NET
VSTS Refactor Pro!
xUnit.net Visual Studio
Moq
Rhino Mocks

13. create a
failing
test
remove write
duplicatio just
n clarify enough
intent to pass

14. RED
Refactor Green

16. The simplest.
The essence.
If you need to write code that is untested,
choose a simpler test.
If the essence approach takes to much time to
implement, choose a simpler test.

17. Small and focused
Intention revealing
Repeatable
Independent
Have no side-effects

18. Description should be
• Domain-specific
• Suitable for customer comprehension
• Understandable in absence of code
Writing descriptions
• Think about behavior
• Think about the context of the behavior
• Focus on the words, not the implementation

20. Fake It(Til You Make It)
Start with hardcoded results and wait until later
tests to force them to become real.
Triangulate To Abstraction
Make the code abstract only when you have two or
more examples.
Obvious Implementation
aka Don't Be Stupid
If you really, really, honestly know the right way to
implement it, then write it that way.