Stop Testing, Start Storytelling (RailsConf 2018)

Stop Testing, Start Storytelling (RailsConf 2018)

Stop trying to be a computer; you're a human! You know what humans are good at? Storytelling. Stop trying to write tests just to get a green test suite, and start telling rich, descriptive stories. Once you have a good story, then you can worry about the implementation details (wait, is testing a form of abstraction and encapsulation?!). In this talk, we look at writing tests as simply telling stories to the test suite. By telling stories about the application (methods, controllers, features, &c.) the suite holds the storyteller accountable for making those stories become, and stay, true.

481a1f18bdd124c255bcf9e79a281ec3?s=128

tmikeschu

April 19, 2018
Tweet

Transcript

  1. Stop Testing. Start Storytelling. Mike Schutte RailsConf 2018 1/30 @tmikeschu

  2. Time Topic 5 About Me 1 Goals 4 Testing Paradigms

    20 Storytelling 8 Demo 2 Wrap-up 2/30 @tmikeschu
  3. [5,1,4,20,8,2].reduce(0, &:+) # => 40 3/30 @tmikeschu

  4. [5,1,4,20,8,2].reduce(0, &:+) # => 40 [5,1,4,20,8,2].sum # => 40 4/30

    @tmikeschu
  5. About Me Detroit Quikly (Rails, React, Node.js, Go) environmental science

    -> sociology -> software development University of Denver -> Indiana University -> Turing -> Quikly runner, musician, reader, writer 5/30 @tmikeschu
  6. Goals 6/30 @tmikeschu

  7. Goals perspective 7/30 @tmikeschu

  8. Goals perspective confidence 8/30 @tmikeschu

  9. Testing Paradigms bonus word: para-dig-MAT-ic (adj) 1 http:/ /www.dictionary.com/browse/paradigm 9/30

    @tmikeschu
  10. Testing Paradigms bonus word: para-dig-MAT-ic (adj) • a framework containing

    the basic assumptions, ways of thinking, and methodolog[ies] [for discovering new ideas] that are commonly accepted by members of a scientific community.1 1 http:/ /www.dictionary.com/browse/paradigm 9/30 @tmikeschu
  11. Test last 10/30 @tmikeschu

  12. Test last • The thing that's supposed to happen is

    the the thing that happens. 10/30 @tmikeschu
  13. Test last • The thing that's supposed to happen is

    the the thing that happens. • ~> It's blue because it's blue ! . 10/30 @tmikeschu
  14. Test last 11/30 @tmikeschu

  15. 12/30 @tmikeschu

  16. Test first 13/30 @tmikeschu

  17. Test first • Writing a test to fit an implementation

    13/30 @tmikeschu
  18. Test driven Behavior driven 14/30 @tmikeschu

  19. Test driven Behavior driven • Implementing code to fit a

    test 14/30 @tmikeschu
  20. Test driven Behavior driven • Implementing code to fit a

    test • "Program to an interface, not an implementation" - GOF 14/30 @tmikeschu
  21. Storytelling and Software Software is always means to an end

    15/30 @tmikeschu
  22. Storytelling and Software Software is always means to an end

    • Function to Feature 15/30 @tmikeschu
  23. Storytelling and Software Software is always means to an end

    • Function to Feature • (HINT: the end is to help users.) 15/30 @tmikeschu
  24. Storytelling and Software (minutes) 16/30 @tmikeschu

  25. Storytelling and Software (minutes) • communication (1) 16/30 @tmikeschu

  26. Storytelling and Software (minutes) • communication (1) • context (3)

    16/30 @tmikeschu
  27. Storytelling and Software (minutes) • communication (1) • context (3)

    • abstraction (1) 16/30 @tmikeschu
  28. Storytelling and Software (minutes) • communication (1) • context (3)

    • abstraction (1) • encapsulation (3) 16/30 @tmikeschu
  29. Communication Users communicate with software. Let's make good listeners. 17/30

    @tmikeschu
  30. Context 18/30 @tmikeschu

  31. Context • :cause && :effect 18/30 @tmikeschu

  32. Context • :cause && :effect • More context = more

    understanding 18/30 @tmikeschu
  33. Context • :cause && :effect • More context = more

    understanding • More understanding = more predictive power 18/30 @tmikeschu
  34. Context • :cause && :effect • More context = more

    understanding • More understanding = more predictive power • More predictive power = more confident decision-making 18/30 @tmikeschu
  35. Context • :cause && :effect • More context = more

    understanding • More understanding = more predictive power • More predictive power = more confident decision-making • More confident decision-making = more happiness! 18/30 @tmikeschu
  36. Context When we tell stories about our software, we write

    better software. 19/30 @tmikeschu
  37. Abstraction 20/30 @tmikeschu

  38. Abstraction • Touching a stove 20/30 @tmikeschu

  39. Abstraction • Touching a stove • Breathing 20/30 @tmikeschu

  40. Abstraction • Touching a stove • Breathing • Muscle memory

    20/30 @tmikeschu
  41. Abstraction • Touching a stove • Breathing • Muscle memory

    • Literally every language 20/30 @tmikeschu
  42. Encapsulation We encapsulate our code, why not our thoughts? 21/30

    @tmikeschu
  43. Encapsulation We encapsulate our code, why not our thoughts? •

    Too many jobs makes you bad at all of them. 21/30 @tmikeschu
  44. Encapsulation Code constrains clarity and imagination. 22/30 @tmikeschu

  45. Encapsulation Code constrains clarity and imagination. • Tests can be

    your compass home 22/30 @tmikeschu
  46. Encapsulation Meta alert! 23/30 @tmikeschu

  47. Encapsulation Meta alert! • Programs solve problems 23/30 @tmikeschu

  48. Encapsulation Meta alert! • Programs solve problems • Programming is

    a problem-solving process 23/30 @tmikeschu
  49. Encapsulation Meta alert! • Programs solve problems • Programming is

    a problem-solving process • Maybe the principles that make better programs can also result in better programming? 23/30 @tmikeschu
  50. User <---------------------> Programmer 24/30 @tmikeschu

  51. Implementing User <-------------------X> Programmer 25/30 @tmikeschu

  52. Storytelling/testing User <X-------------------> Programmer 26/30 @tmikeschu

  53. Crowdsource Demo! 27/30 @tmikeschu

  54. Crowdsource Demo! • What's something you have to implement in

    the near future? Could be anything from function to feature. 27/30 @tmikeschu
  55. Wrap-up 28/30 @tmikeschu

  56. Wrap-up • Testing is a paradigmatic process, not a product.

    28/30 @tmikeschu
  57. Wrap-up • Testing is a paradigmatic process, not a product.

    • Communication: build good listeners 28/30 @tmikeschu
  58. Wrap-up • Testing is a paradigmatic process, not a product.

    • Communication: build good listeners • Context: enable confident decision making 28/30 @tmikeschu
  59. Wrap-up • Testing is a paradigmatic process, not a product.

    • Communication: build good listeners • Context: enable confident decision making • Abstraction: you're good at it, it let's you do cool stuff. 28/30 @tmikeschu
  60. Wrap-up • Testing is a paradigmatic process, not a product.

    • Communication: build good listeners • Context: enable confident decision making • Abstraction: you're good at it, it let's you do cool stuff. • Encapsulation: apply the same discipline to your process as you do to your code. 28/30 @tmikeschu
  61. Wrap-up • Testing is a paradigmatic process, not a product.

    • Communication: build good listeners • Context: enable confident decision making • Abstraction: you're good at it, it let's you do cool stuff. • Encapsulation: apply the same discipline to your process as you do to your code. • Storytelling keeps you closer to users 28/30 @tmikeschu
  62. Action Plan 29/30 @tmikeschu

  63. Action Plan • Develop a pendulum workflow between storyteller and

    developer. 29/30 @tmikeschu
  64. Thank you! 30/30 @tmikeschu