Notes on: Testing Legacy Rails Apps given by Kevin Clark & Rabble Henshaw-Plath Part I – Testing an existing rails

app 1. Do we have legacy rails apps? such thing? 1. apps that were built without testing consideration 2. maybe you ignored testing for a while 2. you need to do testing 1. testing is a form of debugging 2. easier to debug using tests than by clicking refresh a million times 3. How to get started testing an existing app 1. Don't try to do it all at once 2. don't stop work to just write tests 3. make tests a part of the daily process 4. Basics 1. Get rake running 2. create test database 3. make sure your database.yml doesn't thinking Legacy Rails Apps your test database is the same as production or dev 4. try rake again 5. Scaffolding tests are broken 1. if you started your app with scaffolding, you have a bunch of broken tests 2. remove those tests or fix them 6. write a test when you're refactoring something 1. don't write a test for code you're not editing 2. whenever you go in and change methods from old code, add some more tests 7. treat every method as a black box 1. ideal method tests one thing 2. write many different test for each method, if there are lots of inputs or ways it may fail 3. test what goes in and what comes out 4. test the return methods for what they return when they fail as well as when they succeed 8. Different ways to run tests 1. rake test 2. rake test:functionals 3. rake test:plugins 4. rake test:recent 5. test directly: 1. ruby article_controller_test.rb 2. ruby article_controller_test.rb -n /show/ 9. Example [there's no way i'm copying the code ... hopefully he will post it] 1. when you're going in to clean up or refactor code without tests, first write tests to make sure you have a good working state 2. do the refactoring 3. run the tests again, tests should still pass 10. build tests from logs 1. log shows you the parameters sent to the controller 2. use these parameters to write a test that will exactly replicate as if it was coming from a user 3. use real parameters from the logs 11. What to test (controllers)? 1. success code (200) or redirect (302) when appropriate 2. right template is rendered 3. instance variables are assigned

4. object is the object that we wanted 5. run the test ... don't just click refresh to “make sure it works” 12. Test coverage 1. answers the question, have we tested enough/all of our code? 2. rake stats - only gives you a very simple code:test ratio 3. rcov 1. gives you more data, actually tells you which lines you are testing 2. tells you what methods you may have not tested 3. very useful to analyze your test coverage 4. won't tell you though if you have tested every path in each method 13. Autotest 1. automatically tests in the background when you change code 2. keep it running all the time 3. don't even have to commit, it runs tests in real time 14. you can go deeper 1. if you commit a patch to Rails, you need to test 2. if you publish a plugin, you need to test 15. Fixtures 1. fixtures are ugly, not fun 2. alternatives to fixtures: 1. ar_fixtures 2. use mocks 3. fixture scenarios 16. zentest 1. controller and model tests instead of functional and unit tests 2. gives you more assertions 17. focus on the bugs 1. don't do it all at once 2. focus on the bugs 3. don't waste time writing tests for code that already works really good 4. unless you have to refactor it Part II – Heckle 1. What is Heckle? 1. Heckle is a mutation tester 2. quote from the movie Sneakers “To break into people's places to make sure that no one can break into their places” 3. Heckle is like penetration testing or fuzzing for your code 4. tries to make sure that your tests are meaningful 5. analogy: Rspec/Test::Unit is your safety belt 6. analogy: rcov is your airbag 7. analogy: Heckle is your helmet, neck brace, and your fireproof suit 2. Branch Coverage 1. rcov will tell you if a method has been tested at all ... but not if it's good or not, or fully tested 2. Heckle fetches the parse tree 3. ... then mutates the code 4. ... then runs tests 5. ... then rolls back your code to its original state 6. Heckle literally rewrites your methods on the fly 7. it parses your code, figures out all the branches, and mutates every node and runs your test 3. How to use it 1. lots of options

2. easy way is just 'heckle MyController' 3. looks for tests in your test directory and runs those 4. test a action in your controller 'heckle MyController action' 5. output shows you mutations that have survived and which failed 4. Heckle 1.4.0 is out this weekend 1. six new node mutations 2. focused node 3. specify your mutations 5. Run Heckle alongside rcov, not instead of it 6. Use it most when you inherit code that has no tests – to find out where you really need to add tests

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.