The document discusses how test-driven development (TDD) can help address common fears and issues developers experience when working with existing or new code. It argues that while TDD may seem difficult with Rails, the challenges are likely due more to issues with the code structure rather than limitations of TDD or Rails. The document differentiates between hard skills related to TDD tools and techniques versus softer skills around understanding requirements, isolating business logic, continuous delivery, and refactoring tests. It provides suggestions for improving TDD skills like practicing with code katas, extracting business logic into gems, and doing "domain spikes" with in-memory objects to focus on logic alone.

1. Can you TDD Rails?
@andrzejkrzywda
(in love/hate relationship with Rails, since 2004)
Arkency

2. • “What does this code really do?”
• “Can I safely remove it?”
• “I see dead code”
• “I’m afraid to change this code”
• “This code is ugly”
• “Oh, it’s a mock that returns a mock that returns
a mock”
Things developers say

3. Fear/hate of existing code

4. • “Where do I start with this feature?”
• “Will I break anything?”
• “I’ll just add a bool parameter here and an if
there”
• “Changing this will break dozens of tests”

5. Fear of new code

6. hypothesis:
!
TDD can help us with those
problems

7. • “What does this code really do?”
• “Can I safely remove it?”
• “I see dead code”
• “I’m afraid to change this code”
• “This code is ugly”
• “Oh, it’s a mock that returns a mock that returns
a mock”
Things developers say

8. • “Where do I start with this feature?”
• “Will I break anything?”
• “I’ll just add a bool parameter here and an if
there”
• “Changing this will break dozens of tests”

9. Fear-driven coding
is not
fun

10. Fear-driven improvement
is
fun

11. Skills

12. Hard skills
vs
soft skills

13. Hard skills
!
where computers excel

14. Soft skills
!
where humans excel

15. Chess - hard skills
• endings
• openings (theory)
• realizing advantage
• tactics (combinations)

16. Chess - soft skills
• recognize patterns
• understand nuances
• strategy
• plans

17. In a chess game (40-50 moves)
we’ve got about 4-5 critical
positions that require more
thinking

18. Rails

19. Rails - Hard skills
• Rails Controllers API
• Rails views API
• ActiveRecord API
• CoffeeScript/JavaScript
• Ruby stdlib
• refactoring techniques

20. Rails - soft skills
• understand requirements
• implement business rules
• applying refactoring
• splitting modules / services
• isolating from Rails
• isolating from Gems

21. TDD

22. TDD == TestFirst + Refactoring

23. Red
Green
Refactor

24. “but TDD is hard with Rails”

25. The TDD drama
!
“If TDD with Rails is hard, then
something is wrong with TDD.”

26. TDD is fine
Rails is fine
!
Most likely, your code is not fine

27. TDD skills

28. TDD hard skills
• tools - rspec, xunit, guard
• automatic run
• full suite vs partial suite
• TDD JavaScript tools
• IDEs

29. TDD soft skills
• spikes
• GTD
• Continuous delivery (commit after every cycle)
• triangulation
• isolate from the framework (aka the Rails sandwich)
• tests refactoring
• when to mock?

30. Spikes
• “It’s not clear to me, what I need to do”
• a prototype
• throw-away code
• cowboy hacking
• timeboxed
• make notes
• can be temporarily deployed, if it’s “secure” just to feel it

31. Getting Things Done
• “I know what to do, now just do it”
• checklists
• Pomodoro
• procrastination

32. Continuous Delivery
• Commit/push after every red/green/refactor
cycle
• push == deploy
• small steps
• don’t break the existing code
• always green

33. TDD triangulation
• the simplest possible test
• make it green in the stupid way
• next test
• implement with an ‘if’
• next test
• refactor and implement the right way

34. Framework isolation
• controller? - extract service object or a query
object, as early as possible
• model? - move logic to service object
• no need to test ActiveRecord
• extract repository object
• render views with locals

35. tests refactoring
• test is code too
• make it short, elegant, easy to read
• apply Clean Code rules
• feel free to remove some tests

36. when to mock?
• boundaries
• db access

37. How can I improve at TDD?

38. exercising TDD
• code kata
• YouTube: TDD
• extract business logic as a gem, TDD that
• “domain spike” - what if all objects can live in
memory (no db) and there’s no boundaries (http,
api), just objects
• 15 minutes a day

39. It’s all up to you to
learn how to TDD Rails
Thanks!
http://rails-refactoring.com/