0
Email (samnang.chhun@gmail.com)
Blog (http://tech.wowkhmer.com)
Rails Developer
.NET Developer
About Testing!
Test Last or DDD (Design Driven Tests)
Short development iterations
Is a design process
Based on requirement and pre-written test
cases
Tests are your first user...
Unnecessary Codes
Unchangeable Codes
Unintelligible Code
Makes you think about required behavior.
Provides documentation.
Improves quality.
Reduces speculative code.
Less time deb...
I don’t have time to unit test.
The client pays me to develop code, not write
unit test.
I am supporting a legacy applicat...
It forces you to really understand the code.
It forces you to really understand the tests
It forces you to create code tha...
Enabling TDD
TDD Cycle
Choosing the First Test?
Green Bar Patterns
State-based vs. Interaction-based Unit Testing
NUnit         Resharper
MbUnit        TDD.NET
VSTS          Refactor Pro!
xUnit.net     Visual Studio
Moq
Rhino Mocks
create a
              failing
               test




 remove                   write
duplicatio                 just
 n ...
RED




Refactor         Green
The simplest.
The essence.




If you need to write code that is untested,
choose a simpler test.
If the essence approach ...
Small and focused
Intention revealing
Repeatable
Independent
Have no side-effects
Description should be
• Domain-specific
• Suitable for customer comprehension
• Understandable in absence of code
Writing ...
Fake It(Til You Make It)
   Start with hardcoded results and wait until later
   tests to force them to become real.
Trian...
Test Driven Development
Test Driven Development
Test Driven Development
Test Driven Development
Test Driven Development
Test Driven Development
Test Driven Development
Upcoming SlideShare
Loading in...5
×

Test Driven Development

857

Published on

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
857
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
52
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Transcript of "Test Driven Development"

  1. 1. Email (samnang.chhun@gmail.com) Blog (http://tech.wowkhmer.com) Rails Developer .NET Developer
  2. 2. About Testing! Test Last or DDD (Design Driven Tests)
  3. 3. 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
  4. 4. Unnecessary Codes Unchangeable Codes Unintelligible Code
  5. 5. Makes you think about required behavior. Provides documentation. Improves quality. Reduces speculative code. Less time debugging. Confidence in change Discover usability issues early
  6. 6. 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.
  7. 7. 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.
  8. 8. Enabling TDD TDD Cycle Choosing the First Test? Green Bar Patterns State-based vs. Interaction-based Unit Testing
  9. 9. NUnit Resharper MbUnit TDD.NET VSTS Refactor Pro! xUnit.net Visual Studio Moq Rhino Mocks
  10. 10. create a failing test remove write duplicatio just n clarify enough intent to pass
  11. 11. RED Refactor Green
  12. 12. 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.
  13. 13. Small and focused Intention revealing Repeatable Independent Have no side-effects
  14. 14. 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
  15. 15. 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.
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×