Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Like this? Share it with your network

Share

Pragmatic Test Driven Development

on

  • 1,937 views

Slides from Integrum's

Slides from Integrum's

Statistics

Views

Total Views
1,937
Views on SlideShare
1,937
Embed Views
0

Actions

Likes
0
Downloads
16
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Pragmatic Test Driven Development Presentation Transcript

  • 1. Pragmatic Test Driven DevelopmentSunday, January 22, 12
  • 2. Your Host Clayton Lengel-Zigich Certified Scrum Master Certified Scrum Product Owner Certified Scrum Professional clayton@integrumtech.com @claytonlzSunday, January 22, 12
  • 3. Types of TestingSunday, January 22, 12
  • 4. Types of Testing Acceptance Integration UnitSunday, January 22, 12
  • 5. Types of Testing This piece should be 24” These third-party rubber feet should fit Given all of these pieces, I can sit in the chair POÄNGSunday, January 22, 12
  • 6. Types of Testing Acceptance Unit Unit UnitSunday, January 22, 12
  • 7. Types of Testing Feature Feature Feature Acceptance Acceptance Acceptance Unit Unit Unit Unit Unit Unit Unit Unit Unit Feature Feature Feature Acceptance Acceptance Acceptance Unit Unit Unit Unit Unit Unit Unit Unit UnitSunday, January 22, 12
  • 8. Who’s Responsible?Sunday, January 22, 12
  • 9. Who’s Responsible? QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QA QASunday, January 22, 12
  • 10. Who’s Responsible? QASunday, January 22, 12
  • 11. Who Writes Unit Tests?Sunday, January 22, 12
  • 12. Who Writes Acceptance Tests? CUSTOMER Discovery DEV QASunday, January 22, 12
  • 13. Automated TestingSunday, January 22, 12
  • 14. Continuous Integration Continuous integration avoids or detects compatibility problems early ... if you integrate throughout the project in small amounts you will not find your self trying to integrate the system for weeks at the projects end while the deadline slips by. Always work in the context of the latest version of the system.Sunday, January 22, 12
  • 15. Continuous Integration SCM Build Server SCMSunday, January 22, 12
  • 16. Continuous Integration Compilation Build Executes Tests Server Defines StatusSunday, January 22, 12
  • 17. Continuous Integration 10 MINUTE BUILDSunday, January 22, 12
  • 18. Test First ProgrammingSunday, January 22, 12
  • 19. Test First ProgrammingSunday, January 22, 12
  • 20. Test Driven DevelopmentSunday, January 22, 12
  • 21. Test Driven Development Test CodeSunday, January 22, 12
  • 22. Test Driven Development Failing Passing RefactoredSunday, January 22, 12
  • 23. Test Driven Development Failing Failing Passing Acceptance Test Unit Test Unit Test RefactorSunday, January 22, 12
  • 24. Test Driven Development Code Code Code Code Test Code Code Time Test Code Test Code Test Code Test TimeSunday, January 22, 12
  • 25. Frameworks and ToolsSunday, January 22, 12
  • 26. Frameworks And Tools xUnitSunday, January 22, 12
  • 27. Frameworks And Tools xUnit Language JUnit Java NUnit .Net TestUnit Ruby QUnit JavaScript PhpUnit PHPSunday, January 22, 12
  • 28. Pair ProgrammingSunday, January 22, 12
  • 29. Pair Programming Write Test Write CodeSunday, January 22, 12
  • 30. Tutorial #1Sunday, January 22, 12
  • 31. Test Unit Fundamentals test_strike_strike_ball_ball_ball vs test_full_countSunday, January 22, 12
  • 32. Test Unit Fundamentals Setup Assertion Assertion Assertion Tear DownSunday, January 22, 12
  • 33. Test Unit Fundamentals assert(test, msg = (nomsg = true; nil)) assert_equal(exp, act, msg = nil) assert_no_match(regexp, string, msg=nil) assert_not_equal(exp, act, msg=nil) assert_not_nil(exp, msg=nil) assert_not_same(expected, actual, message="") assert_nothing_raised(*args) assert_nothing_thrown(msg=nil) assert_raise(*args, &b) assert_respond_to(obj, meth, msg = nil)Sunday, January 22, 12
  • 34. TDD RUles 1.Only write code that makes a test pass 2.Only write enough of a test to make it fail 3.Only write enough code to make a test passSunday, January 22, 12
  • 35. Tutorial #1 In pairs, write a program that can play the game of hangman. 50m Activity TimeSunday, January 22, 12
  • 36. Mocking & STUBBING Mocks vs. Stubs Indirect Outputs vs. Indirect Inputs Objects vs. Methods Behavior vs. StateSunday, January 22, 12
  • 37. Mocking Warehouse ? Order ? ?Sunday, January 22, 12
  • 38. Mocking order.items.each do |item| warehouse_item = Warehouse.find(item) warehouse_item.stock_reservation.reserve end Warehouse WarehouseItem Order StockReservationSunday, January 22, 12
  • 39. Mocking Warehouse.reserve(items) Warehouse OrderSunday, January 22, 12
  • 40. Mocking fake_warehouse = mock(Warehouse) assert( fake_warehouse.received("reserve") .with(items), "Expected the warehouse to check its stock" )Sunday, January 22, 12
  • 41. STUBBING “If any items are out-of-stock, the system should prevent the order from completing” CUSTOMERSunday, January 22, 12
  • 42. STUBBING def test_out_of_stock order = Order.new item1 = Item.new(:sku => "abc") item2 = Item.new(:sku => "def") order.items = [item1, item2] stock_item1 = StockItem.new(:sku => zyx) ... endSunday, January 22, 12
  • 43. STUBBING def test_invalid_items Warehouse.stub(:reserve) .and_raise(OutOfStockException) assert_raise(OutOfStockException) do order.complete end endSunday, January 22, 12
  • 44. Tutorial #2Sunday, January 22, 12
  • 45. Tutorial #2 In pairs, write a program that implements Conway’s game of life. 45m Activity TimeSunday, January 22, 12
  • 46. Game of Life “The universe of the Game of Life is an infinite two- dimensional orthogonal grid of square cells, each of which is in one of two possible states, alive or dead. Every cell interacts with its eight neighbors, which are the cells that are horizontally, vertically, or diagonally adjacent. At each step in time, the following transitions occur:”Sunday, January 22, 12
  • 47. Game of Life: Rules Any live cell with fewer than two live neighbors dies, 1 as if caused by under-population. Any live cell with two or three live neighbors lives on 2 to the next generation. Any live cell with more than three live neighbors dies, 3 as if by overcrowding. Any dead cell with exactly three live neighbors 4 becomes a live cell, as if by reproduction.Sunday, January 22, 12
  • 48. ClosingSunday, January 22, 12
  • 49. Test Feedback Listen to your testsSunday, January 22, 12
  • 50. Code Coverage “If we’re not at 90% code coverage you’re all working on Saturday.” MANAGEMENT “assert(true)” DEVSunday, January 22, 12
  • 51. Continuously Integrate Live and Die by the buildSunday, January 22, 12
  • 52. Plan to Succeed BDD Write tests before you plan the implementation Failing Unit Test TDD Passing Unit Test RefactorSunday, January 22, 12