TDD for Rails devs. The long story.

Transcript

1. VOLODYA SVEREYUK Lviv #pivorak Ruby dev
6. TDD FOR RAILS DEVELOPER
8. Test-driven development (TDD) is a software development process that relies on the - repetition of a very short development cycle: • Requirements are turned into very specific test cases • Then the software is improved to pass the new tests, only
9. Kent Back rediscovered 2003
10. 1. Add a test 2. Write a code 3. Run tests 4. Refactor code 5. Repeat 3-4 WTF is TDD ?
11. WHY WE NEED TESTS ?
12. 1. Test it's also a code 2. Costs time (money) 3. Slow down delivery 4. Hard. Need to know how to 5. Painful hotfixes or workarounds We don't need tests
13. Simple code
14. Naive refactoring
15. Only tests can save you
16. Bloody screen
17. Good test suite - safety sleeping
18. RED GREEN REFACTOR
19. RSPEC
20. RSpec • http://rspec.info/ • Describe • Context • IT (expect)
21. Cost time No test for 1st time: Write a code - 10 min Check - 5 min Deliver With test for 1st time: Write a test - 10 min Write a code - 10 min Deliver VS.
22. Cost time Write code for N time: Write a code - 10 min Check - 5 min Check dependent code - N x 5 min Deliver
23. Slow down delivery
24. HARD • You fight with syntax • You don't know API • You don't know how to test • You don't know what to test • You are a lazy ass
25. I don't fu#king care
26. 1. Tests are always part of the development 2. Never tests should be extracted into separate task or estimation Remember !
27. HOW 1. Setup ENV 2. Configure ENV 3. Just do it! https://github.com/rspec/rspec-rails
28. WHAT 1. Every single class 2. Every public method 3. Every single endpoint 4. Every single workflow 5. Edge cases
29. NOT 1. Internet (HTTP) 2. Libraries 3. Framework / Language
30. TEST UNIT INTEGRATION ACCEPTANCE
31. USER
32. TEAM
33. TEAM
34. UNIT?
35. UNIT!
36. REAL UNIT TEST
37. NEW GREAT FEATURE!
38. BDD
40. And one more stupid example
41. STUPID EXAMPLE
42. STUPID DB INSERT
43. YOU DON’T NEED A DB !
44. 2 UNITS 0 INTEGRATION
45. INTEGRATION ACCEPTANCE UNIT UNIT UNIT UNIT INTEGRATION UNIT UNIT Test architecture
46. ATTENTION! REAL WORLD
 EXAMPLES !!1
47. SERVICE SPEC
48. ACCEPTANCE
49. REST API
50. https://github.com/brooklynDev/airborne
52. https://github.com/zipmark/rspec_api_documentation
54. GRAPHQL API
55. https://github.com/vcr/vcr
56. VCR.use_casette
57. https://github.com/guard/guard-rspec
61. https://github.com/colszowka/simplecov
63. spec_helper.rb
64. Focus
65. rspec —profile
66. CI / CD
67. GOOD TESTS SHOULD BE 1. Easy to write 2. Easy to read 3. Reliable (coverage >95%) 4. Fast 5. Truly unit, not integration
68. BAD TESTS CAN BE 1. Mess 2. DB data sets 3. Random fails 4. Slow 5. Coupled
69. NEVER ASK PERMISSIONS FOR WRITE TESTS 1
70. YOUR TEST SUITE IS YOUR SAFETY BELT 2
71. BAD TESTS BETTER THAN THEIR ABSENCE 3
72. FOR BAD
 CODE YOU CAN'T WRITE GOOD TEST 4
73. IF YOUR TEST LOOKS LIKE A S#!T YOUR CODE IS A S#!T 5
74. Questions !
75. t.me/svcast