TDD with Rails

Slide 1: TDD with Rails AndrzejKrzywda.com RuPy 2008 Poznan, Poland

Slide 2: Who am I?

Slide 3: Andrzej Krzywda • Developing software since 2000 • Java/.NET/PHP/Python/Rails

Slide 4: Now mostly Rails

Slide 5: First Rails app in November 2004

Slide 6: I started doing TDD in 2001

Slide 7: Also involved in a project called Resolver One, written in IronPython

Slide 8: Started a Rails company in 2007

Slide 9: Test Driven Development

Slide 10: The goals in a software project

Slide 11: Requirements are goals

Slide 12: What helps in achieving goals?

Slide 13: Goal visualization

Slide 14: Software requirements

Slide 15: TDD (in a high level) is about visualizing goals.

Slide 16: Software developers are responsible for visualization of other people goals

Slide 17: What is TDD?

Slide 18: TDD is about writing tests BEFORE writing production code.

Slide 19: What kind of tests?

Slide 20: Be pragmatic.

Slide 21: TDD definitions

Slide 22: TDD is like politics or religion

Slide 23: Everyone thinks he’s right

Slide 24: I think they are wrong...

Slide 25: My TDD

Slide 26: Acceptance tests + Unit tests

Slide 27: Acceptance tests + Unit tests

Slide 28: Definitions

Slide 29: Acceptance test is a test from the user’s perspective.

Slide 30: Unit test is a test for a class.

Slide 31: Which are more important?

Slide 32: It depends.

Slide 33: The level of test coverage Unit tests Acceptance tests 100 75 50 25 0 2001 2003 2006 2008 Java IronPython Rails

Slide 34: Why?

Slide 35: Why • Rails is a more mature community (in the TDD aspect) • So many great tools • REST! - almost no need to test controllers • Almost only model unit tests • Acceptance tests, trivial with RSpec Stories + Webrat

Slide 36: Acceptance tests

Slide 37: Doing TDD means to have many tests.

Slide 38: TDD is a good requirements management technique

Slide 39: TDD • 3 x D rule • Defense (Tests) • Design • Documentation

Slide 40: ???

Slide 41: Let’s take an example.

Slide 42: A blog application

Slide 43: We are about to add a ‘commenting’ feature.

Slide 44: How can we visualize it?

Slide 45: As a Rails developer?

Slide 46: > script/generate migration CreateCommentsTable content:text class Post < ActiveRecord::Base has_many :comments end class Comment < ActiveRecord::Base belongs_to :post end <%= render_collection @post.comments %>

Slide 47: As a software developer?

Slide 48: $$$$

Slide 49: Someone pays for your work, right?

Slide 50: What users are involved in the blog commenting feature?

Slide 51: A blog reader

Slide 52: As a blog reader I want to comment on a blog post So that I can share my thoughts on the topic

Slide 53: A blog owner / author

Slide 54: As a blog owner I want to display comments So that other people can see how cool my blog is.

Slide 55: As a blog owner I want to moderate comments So that there is no spam

Slide 56: As a blog owner I want to display captcha images So that there is no spam

Slide 57: Another blog reader

Slide 58: As another blog reader I want to reply to other comments So that I can prove they are wrong

Slide 59: As an RSS subscriber...

Slide 60: As a bad person...

Slide 61: As a bad person I want to use SQL Injection So that I can break your blog and become famous.

Slide 62: The structure

Slide 63: Spikes / prototyping

Slide 64: User stories

Slide 65: Show your customer the user stories.

Slide 66: Discuss it.

Slide 67: Estimate it.

Slide 68: Prioritize.

Slide 69: Implement it.

Slide 70: Split it into tasks which are usually related to scenarios.

Slide 71: TDD helps you focusing on one task at a time.

Slide 72: There’s always exactly one test failing.

Slide 73: Tools

Slide 74: RSpec stories Webrat

Slide 75: Selenium RC Watir

Slide 76: RSpec / BDD

Slide 77: RSpec stories != RSpec examples

Slide 78: RSpec stories is for acceptance tests

Slide 79: ‘RSpec examples’ is a unit testing tool.

Slide 80: The process

Slide 81: List the scenarios.

Slide 82: RSpec story Story: Commenting on a blog As a blog reader I want to comment So that I can share my thoughts about the article Scenario: Simple adding of a comment Given an existing blog post And a blog reader writing a comment When he submits it Then it appears below the blog post stories/comments

Slide 83: require File.join('stories', 'helper') steps_for :comments do end with_steps_for :comments do run 'stories/comments', :type => RailsStory end

Slide 84: require File.join('stories', 'helper') steps_for :comments do Given "an existing blog post" do @post = Post.create(:title => 'title', :body => 'body') end end with_steps_for :comments do run 'stories/comments', :type => RailsStory end

Slide 85: require File.join('stories', 'helper') steps_for :comments do Given "an existing blog post" do @post = Post.create(:title => 'title', :body => 'body') end Given "a blog reader writing a comment" do visits '/' clicks_link 'Read more...' fills_in 'comment[content]', :with => 'First!' end end

Slide 86: RSpec story runner require File.join('stories', 'helper') steps_for :comments do Given "an existing blog post" do @post = Post.create(:title => 'title', :body => 'body') end Given "a blog reader writing a comment" do visits '/' clicks_link 'Read more...' fills_in 'comment[content]', :with => 'First!' end stories/comments.rb

Slide 87: RSpec story runner When "he submits it" do clicks_button "Add" end Then "it appears below the blog post" do visits '/' clicks_link 'Read more...' response.body.should have_text 'First!' end end with_steps_for :comments, :posts do run 'stories/comments', :type => RailsStory end stories/comments.rb

Slide 88: Run the test

Slide 89: It fails

Slide 90: Implement one step at a time

Slide 91: If it’s not trivial start with a spec first.

Slide 92: RSpec example

Slide 93: Webrat • Bryan Helmkamp • github.com/brynary/webrat • manipulates DOM • builds POST from DOM

Slide 94: Problems?

Slide 95: Slow builds

Slide 96: Fragile, unreliable tests

Slide 97: What about the scientists opinions?

Slide 98: Thirumalesh Bhat and Nachiappan Nagappan. Evaluating the efficacy of test- driven development: industrial case studies. In ISESE ’06: Proceedings of the 2006 ACM/IEEE international symposium on Empirical software engineering, pa- ges 356–363, New York, NY, USA, 2006. ACM. Gerardo Canfora, Aniello Cimitile, Felix Garcia, Mario Piattini, and Corrado Aaron Visaggio. Evaluating advantages of test driven development: a controlled experi- ment with professionals. In ISESE ’06: Proceedings of the 2006 ACM/IEEE inter- national symposium on Empirical software engineering, pages 364–371, New York, NY, USA, 2006. ACM. Steven Fraser, Dave Astels, Kent Beck, Barry Boehm, John McGregor, James New- kirk, and Charlie Poole. Discipline and practices of tdd: (test driven development). In OOPSLA ’03: Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pages 268–270, New York, NY, USA, 2003. ACM. Ivana Turnu, Marco Melis, Alessandra Cau, Michele Marchesi, and Alessio Setzu. Introducing tdd on a free libre open source software pro ject: a simulation expe- riment. In QUTE-SWAP ’04: Proceedings of the 2004 workshop on Quantitative techniques for software agile process, pages 59–65, New York, NY, USA, 2004. ACM.

Slide 99: What are the consequences of doing TDD?

Slide 100: I don’t use debuggers.

Slide 101: Simpler, thus better design

Slide 102: Frequently asking the question: “How would I test it?”

Slide 103: After many years of doing TDD, I find it VERY difficult to work with untested code.

Slide 104: Unit testing tips • One assertion per test method • Write the assertion first • Thin controllers, fat models • REST • Fixtures, it’s easier without them • Specs output as a documentation

Slide 105: Quotes

Slide 106: “TDD was the single most effective software development habit I adopted”

Slide 107: “My impression is that it's intuitive the way riding a bicycle is intuitive. Extremely UN-intuitive for the child who is learning, but to the adult hardly anything but common sense and difficult to unlearn. That said, as a developer who's fallen down and scraped his knee... since I need to get from point A to point B fast, I know how to run already so I still do that.”

Slide 108: “TDD doesn't work very well when you're trying to work on something new - try a spike instead, and follow with test-driven coding later”

Slide 109: “It’s not clear how to split tests into suites”

Slide 110: “TDD is intuitive once you start doing it”

Slide 111: “You have to start thinking in a different way”

Slide 112: “TDD is only one thing, don’t forget about the others: refactoring, code quality”

Slide 113: “Writing good tests may be difficult for beginners”

Slide 114: “I can’t achieve a 100% code coverage”

Slide 115: My thoughts

Slide 116: A different way of thinking

Slide 117: I always think “How can I test that” instead of “how do I implement it”

Slide 118: Live coding

Slide 119: Thank you! • http://AndrzejKrzywda.com • Rails consulting, training • Feel free to email/IM me with TDD questions • andrzejkrzywda@gmail.com