Tdd - introduction

867 views
826 views

Published on

Introduction to Test Driven Development
Software OpenTalks in Tabriz

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

No Downloads
Views
Total views
867
On SlideShare
0
From Embeds
0
Number of Embeds
419
Actions
Shares
0
Downloads
19
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Tdd - introduction

  1. 1. Software OpenTalks :// . .http tabrizsoftware opentalks co@SamadKoushan test-Driven Development test-Driven Development
  2. 2. Programming in RealProgramming in Real DeadLine Error Error Warning Notice Warning WarningWarning Notice Notice Notice Notice
  3. 3. Alpha VersionAlpha Version Alpha Version!!! Who would get off ?
  4. 4. Alpha VersionAlpha Version A group of ten top software engineers is sent to a class for aspiring managers. The teacher walks in and asks this question: "You work for a software company which develops avionics (software that controls the instruments of an airplane). One day you are taking a business trip. As you get on the plane you see a plaque that says this plane is using a beta of the software your team developed. Who would get off?" Nine developers raised their hands. The teacher looked at the tenth and asked, "Why would you stay on?" The tenth said, "if my team wrote the software, the plane would not get off the ground, much less crash."
  5. 5. Automated TestingAutomated Testing This is programming, you should never just hope that your code works properly, you should be able to prove it and prove it again and again, every step of the way, from the very first lines of code you write, all the way through deploying the application.
  6. 6. Automated TestingAutomated Testing Uncle Bob: The only way to go fast, is to go well.
  7. 7. Automated TestingAutomated Testing ُTDD is not about how to test software! We are not talking about: - beta testing - performance testing - stress testing - integration testing - regression testing - usability testing - ...
  8. 8. Automated TestingAutomated Testing Unit testing: testing we do as programmers not as end-users. We are testing the code itself. Not just the results we may get from clicking button on a user interface. This is about us, testing the individual units of our code, smallest logical piece as possible. We are proving that single class, works the way that class supposed to. If we passing these particular values into that particular method, we will get this specific result back, and then we go ahead and prove that this is true.
  9. 9. Automated TestingAutomated Testing Automated vs manual testing Extra Bonus: modifying Having automated unit tests allow us to easily validate that any changes we made one place, tomorrow or six month later, doesn't break something that we did earlier. We will write code that tests our application code, so we have our application code and saved right along side, our simple repeatable testing code.
  10. 10. TDD vs Unit TestingTDD vs Unit Testing It is not Programming unit test It is Test Driven Development Unit test: Wrtie code → write test TDD: Wrtie test → write code
  11. 11. QAQA Does TDD Work for everything? - NO - multi threading - security options - UI testing - Game development Best practice : 90% or 80% Code Coverage
  12. 12. QAQA Am I supposed to write all my tests first? 9:00:00 AM Write a test 9:00:20 AM see test fails 9:00:30 AM start writing code to just pass the test
  13. 13. QAQA We have testers, do they write these tests? You are coding so you have to write unit tests yourself
  14. 14. QAQA TDD does not fix every issues! -That's right! -Gives you confidence -Gives you documentation -Free you from The Debugger
  15. 15. TDDTDD
  16. 16. HOWHOW Writing our test class?
  17. 17. FrameworkFramework SUnit SmallTalk Junit Java PHPUnit PHP Nunit .NET PyUnit Python CppUnit C++ …. ETC Xunit Frameworks
  18. 18. AssertAssert I assert that the earth moves around the sun - Not asking a question - Not a IF - Not Opinion - Stating that something be true - Can be positive or negative - Not replacing exception handler or error messages - One logical Assertion per test - Each test should have only one reason to fail
  19. 19. AssertAssert
  20. 20. simpleTestsimpleTest Write a test
  21. 21. simpleTestsimpleTest Write a test and Watch it fails
  22. 22. simpleTestsimpleTest Write a code and run test again
  23. 23. simpleTestsimpleTest refactor
  24. 24. TDDTDD
  25. 25. TDDTDD
  26. 26. AAAAAA
  27. 27. AAAAAA
  28. 28. Testing for Expected ExceptionsTesting for Expected Exceptions
  29. 29. Testing for Expected ExceptionsTesting for Expected Exceptions
  30. 30. Testing for Expected ExceptionsTesting for Expected Exceptions
  31. 31. Setting Up and Tearing DownSetting Up and Tearing Down
  32. 32. Setting Up and Tearing DownSetting Up and Tearing Down
  33. 33. Setting Up and Tearing DownSetting Up and Tearing Down
  34. 34. Setting Up and Tearing DownSetting Up and Tearing Down
  35. 35. QAQA Do I test getters and setters? Do I test private methods? Can I combine multiple test classes? Test Suites How do I control the order of tests? You cannot!
  36. 36. Mock ObjectsMock Objects
  37. 37. Mock ObjectsMock Objects
  38. 38. Mock ObjectsMock Objects
  39. 39. Mock ObjectsMock Objects
  40. 40. Mock Objects And Fake ObjectsMock Objects And Fake Objects
  41. 41. ...And More...And More Test-driven Development By Example Kent Beck Addison Wesley Refactoring: Improving the Design of Existing Code Martin Fowler , Kent Beck , ... Addison Wesley Growing Object-Oriented Software, Guided by Tests Steve Freeman Addison Wesley

×