Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Ähnlich wie WTF TDD?
Ähnlich wie WTF TDD? (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
WTF TDD?
- 1. WTF TDD? Jeremy Weiskotten Terrible Labs
- 3. @doctorzaius
- 4. The year was 1996...
- 5. Srsly.
- 6. So what changed? • Open source movement • Agile, Lean, Scrum • Extreme Programming
- 7. EXTREME! PROGRAMMING! O/ LOL • Shared ownership • Continuous integration • Sustainable pace • Pair programming • Test-Driven Development (TDD/BDD)
- 9. Refactoring • Improving the design of existing code (without changing its behavior) • Make a small change, run your tests. • Ifit takes more than a day, you’re rewriting, not refactoring.
- 10. legacy_code/README • “Legacy code” is code that doesn’t have tests. • It’s always easier to test new code than to bring legacy code under test.
- 11. Stay loose. • Loosely coupled objects are easier to test in isolation • Dependency injection, Strategy pattern • “awkward collaborators” (Feathers)
- 12. Is TDD worth it?
- 13. ZOMG RESEARCH • TDD teams took 15-35% longer • TDD teams created 40-90% fewer bugs “If we control for defect rate, is TDD faster?” http://grokcode.com/439/test-driven-development-and-the-meaning-of-done/
- 14. We have the tools. We have the talent. Srsly.
- 15. Ruby Testing Frameworks • Test::Unit • RSpec • MiniTest • Shoulda • TestRocket http://codebrawl.com/articles/contest-rundown-ruby-testing-libraries
- 16. Integration Testing • watir • webrat • cucumber • steak • capybara • capybara-webkit
- 17. Factories because fixtures suck • Factory Girl • Fabrication • Machinist • Sham • Object Daddy
- 18. Rails/ActiveRecord • shoulda-matchers • valid_attribute • email-spec
- 19. Stubbin’ and Mockin’ and Fakin’ • mocha • vcr • FlexMock • timecop • rr • faker, ffaker • fakeweb • bourne • webmock • Mock::Turtle • faraday
- 20. Feedback, early & often • spork • autotest • autospec • ZenTest
- 21. Standards & Practices • metric_fu • reek • flay • rcov • flog • CoverMe • roodi • SimpleCov • rails_best_practices • saikuro
- 22. We’re religious about testing. • We believe. • We argue about the details. • Some more than others! • That’s OK.
- 23. “I do not write tests for my code.”
- 25. Thanks for still being here!
Hinweis der Redaktion
- \n
- I recently started Terrible Labs with Joe Lind. We’re a Rails, Node.js, and mobile development consultancy in Boston.\n
- I’m doctorzaius on Twitter.\n\nDr. Zaius is a character from Planet of the Apes. He had two contradictory titles: “Minister of Science” and “Chief Defender of the Faith”. It’s interesting how a scientific, rational mind can also form an irrational attachment to an idea, a tool, or a process. Zaius was afraid of new ideas. He was kind of a dick.\n\nI think Dr. Zaius was a doctor the same way Jerry Falwell is a doctor. I’m not actually a doctor either. I never even got a college degree. But if you want to give me an honorary degree, I would accept it and say really nice things about you whether they’re true or not.\n
- I got my first “real” job as a programmer in 1996 after high school, a few weeks before my 19th birthday.\n\nThings were different back then.\n\nInstead of user stories, we wrote - or more often we were given - big specifications with lots of signatures on them. These specs were rarely updated to reflect new knowledge, feature creep, or feature reduction.\n\nSoftware architects designed complex systems, often without ever writing a line of code to implement them. Sometimes they’re called “architecture astronauts”.\n\nInstead of writing unit tests, we had a QA department who wrote test plans based on the specs and clicked on a lot of stuff at the end of a long development cycle (sometimes months).\n\n
- It was a slow and expensive way to build software. I worked this way until around 2004. A lot of companies still work this way. Some of YOU might still work this way.\n
- \n
- Extreme programming is a stupid name for an awesome set of principles.\n\nShared ownership gives every developer the right to change others’ code. It also implies shared responsibility.\n\nContinuous integration means a shorter feedback cycle. You should know as soon as possible if your shit doesn’t work or if you broke something. The sooner you know, the cheaper it is to fix.\n\nA sustainable pace means we don’t work 16 hours a day and burn ourselves out. We do better work and are more valuable to our employers or clients when we have enough rest and spend time doing things other than programming.\n\nPair programming helps us focus and learn from each other.\n\nTDD helps us do these things. With a good set of tests, we can change other people’s code without breaking it as easily. We can easily and quickly run our automated tests when we integrate with other changes. We don’t spend as much time working on things that aren’t important.\n
- \n
- \n
- \n
- Because loosely coupled (single responsibility) objects are easier to test in isolation, when writing tests first the path of least resistance is a loosely coupled design. You don’t tend to write procedural code with TDD.\n
- \n
- \n
- \n
- Previous entries: context, matchy, bacon\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- “I do not write tests for my code. I do not write very many comments. I change styles very frequently. And most of all, I shun the predominant styles of coding, because that would go against the very essence of experimentation. In short: all I do is muck around.”\n- Why the lucky stiff\n\nhttp://my.opera.com/adrnlnrsh/blog/show.dml/11402771\n
- \n
- \n