Podcast: Play in new window | Download (Duration: 1:13:38 — 101.1MB)
Panel
- Charles Max Wood (twitter github Teach Me To Code)
- David Brady (blog twitter github ADDcasts)
- James Edward Gray (blog twitter github)
- Josh Susser (twitter github blog)
- Ryan Bates (twitter github RailsCasts)
Discussed in this Episode
When not to test:
- In a new startup trying to get funding
- It’s too hard to write the test
- It’ll take too long
What is a test?
- Verifies code functionality
- Automated testing
- Manual tests
Only run the tests you need to run.
Testing myths:
- It’s too hard to test this.
- This is usually a design flaw.
- Forked processes are hard to test.
- Complicated User Interface stuff.
- It’s better/easier to fix it first.
- You can’t test code in Rake Tasks.
- Testing is hard or Writing code and tests is harder than writing code.
- Is this code for “Testing requires discipline?”
- Don’t test “One shot code.” – You’re only going to run it once, until you need to run it again.
- You don’t have to test migrations.
TDD gives you a regression test suite and better design.
Do you not test because of ROI:
- Routine tasks are diminished ROI in design.
- Duplicate code
- Low Risk code
Testing Javascript from Rails:
The clock is a global variable.
Code coverage:
- Ryan likes to have 100% code confidence.
- Coverage means exercise, not correct functionality.
- Rails’ migration code didn’t get covered and then got crufty.
- Code that is difficult to test is difficult to refactor, reuse, extract, and modularize. It’s a “meta-code smell.”
Picks
- Moleskine notebooks (David)
- A notebook (David)
- Pry (on Railscasts)(Josh)
- Showing appreciation for your friends (Josh)
- Ruby Weekly (James)
- RailsCasts (James)
- Harvest (Chuck)
- Netflix App (Chuck)
- Audible.com (Chuck)
- Go board game (Ryan)
- Foreman (Ryan)
{ 6 comments… read them below or add one }
Autotest has similar test-run pattern as Guard. I however usually run it with the “-c -f” flags which makes it never run the entire test-suite. Then I only run the whole thing manually by hitting ctrl+c in the autotest tab when I it makes sense, like before I actually commit something (current project has something like a 2 minute long test suite).
Regarding testing rake tasks. I usually do the library approach mentioned, which is fine if that’s all we need to do.
But sometimes the rake stuff is more involved than that. The tasks might call out to each other or “inherit” from other tasks. Or they expect certain env variables as arguments. Admittedly when I run into these problems the rake tasks I’m dealing with are usually not in my code – and we can put the blame on the guys who created the rake mess in the first place.
But in case you find yourself in the situation when you can’t run away from testing rake in itself – how do you go about it? Shell out to an actual rake call or invoke the tasks using the ruby api?
A concrete example of rake stuff getting messy seems to be Resques resque:work task which you might all be familiar with. There was a bunch of patch releases coming out in the past weeks because they tried to get some inherited :preload task to work correctly and I believe they never wrote any tests for it. Is this a sign that rake is being used in a wrong way or something else? Is rake a bad idea for daemonized processes? Is there a better way of doing it?
Regarding how to migrate from scratch in activerecord – the “official” way is the db:setup task which runs db:create -> db:schema:load -> db:seed.
A good sanity check is to make a habit of running db:reset often (which runs db:drop -> db:setup). If that runs fine you’re in a good spot. It also enforces you to think about how to populate fixture data that might help get your development environment up and running which is helpful both to yourself (in that you don’t have to worry about messing up your current development data) and any new developers coming into your project.
Best option is to switch to Mongodb and get rid of migrations altogether though
I always put “rake db:migrate:reset” in front of every CI run, to make sure the migrations still work. I don’t care all to much about the schema.
For stubbing time, I usually go with Delorean in stead of Timecop, just because of the name.
I would also like to point out that cucumber-js is becoming more and more complete each day: https://github.com/cucumber/cucumber-js
Good discussion – I think Ryan wanted to link to http://govsgo.com/ – which is awesome!
Thanks for all the great work.
I’d like to show some appreciation here for all the time you guys are putting in for making these podcasts.
Thanks!