June 2007 Archives

I'd like feedback on the following curriculum. I'd especially like to know what you guys think of taking a "test first" approach to teaching a language like ruby. TDD on Week 3. Too early? Students should have some prior knowledge in programming, but not necessarily OO, testing, or dynamic languages. You think it is too much?

RubyCurriculum.pdf (32K)

Personally, I think it'll be a medium sized hurdle that should allow the rest of the quarter to go by a bit smoother. All homework will be test driven, allowing the students to know ahead of time that they're right or wrong.

What do you think?

I use autotest almost exclusively. It is very rare that I run tests via rake these days so it is embarrassing when something fails via rake and not via autotest. It makes me look bad.

My latest snafu was regarding fixtures. See, the project prepopulates the test db and I started migrating them away from using the fixture calls they were using. When I use my typical rake nuke rule, it'll scrap and rebuild everything, including repopulating the db. autotest is happy as a clam. But rails' test:units does a prepare each time, nuking anything we put in there. I've seen a lot of weird hacks to deal with this, but I just came up with one I finally like:

# ensure we always populate the test db
%w(units functionals integration).each do |type|
  Rake::Task["test:#{type}"].prerequisites.push "db:test:populate"
end

db:test:populate is up to you, do what you need to do. For us, it just ensures we do a db:fixtures:load with RAILS_ENV=test.

This way, no matter HOW you run your tests, either by default rule or by specifying one of the phases you're interested in, you'll always do that populate.

zenspider: today be the day
terraalien: Sure is :)
terraalien: I've contemplated picking it back up... but I have a five day old I'd rather spend time with :)
zenspider: fair 'nuff
zenspider: would ye like to craft a hand-off eeee-mail?
terraalien: Sure.

zenspider: yarr matie. ye be sending the email handing over the ship or we mutiny and throw ye overboard!
terraalien: Sorry... it's turned in to a blog post... it is in progress, though, I promise.
zenspider: yarrrrr ruby core don't be readin' yer blog
terraalien: I'll send out an email with a link :)
zenspider: that be acceptable matie

Yarr! We mutiny and be takin' over test/unit!!! She's a saucy wench with too much meat on 'er bones for our taste. Expect an over'aul soon! Savvy?

Today, bad-ass Seattle.rb just got a little less bad-ass.

Evan Phoenix, a ruby bad-ass and long-standing member of the Seattle Ruby Brigade, is packing up his stuff and moving to LA. A voluntary move on his part. His lovely wife is finally getting into broadcast and it is the right place to be for her.

But it is still a sad day for the rest of us. We wish him the best of luck.

I just had a bug on autotest get diagnosed by the filer:

"The root cause is that I have "require 'turn'" in my project (which provides prettier Test::Unit output) but Autotest::handleresults isn't designed to parse turn's output."_

This was an advanced issue caused by turn (I do hope he files a bug against turn), and solved simply be removing it.

I've seen much simpler issues that can be nearly as confusing. For example, several projects I've worked on that generated thumbnails or index files in RAILS_ROOT, triggering autotest to rerun. This can be confusing, but there is an easy way to figure this stuff out. Run autotest -v and it'll tell you what file changes it detected before rerunning... Then it is a matter of changing your code or adding a .autotest like so:

Autotest.add_hook :run do  |at|
  at.exceptions = /^(?:\.\/)?(?:db|doc|log|public|script|tmp|filestore|vendor\/r
ails)|\.svn|(?:.*_flymake\.rb$)/
end

Ugly... I know. I'll come up with a more flexible means of adding a single exclusion.

Heckle is a mutation tester. It modifies your code and runs your tests to make sure they fail. The idea is that if code can be changed and your tests don't notice, either that code isn't being covered or it doesn't do anything.

Changes:

1.4.1 / 2007-06-05

• 3 bug fixes:

  • Add zentest as a heckle dependency. Closes #10996
  • Fixed heckling of call with blocks.
  • Fix testunitheckler's test_pass? so it returns the result of the run rather than ARGV.clear

• http://www.rubyforge.org/projects/seattlerb

ruby2ruby provides a means of generating pure ruby code easily from ParseTree's Sexps. This makes making dynamic language processors much easier in ruby than ever before.

Changes:

1.1.6 / 2007-06-05

• 2 minor enhancements:
  • Extended tests for dstr/dsym/drgx to test against embedded slashes and quotes.
  • Updated for dasgn_curr changes to PT.

• 2 bug fixes:

  • Fixed a bug with begin/rescue/ensure.
  • Fixed argscat and blockpass bug. blah(42, *args, &block) handled.

• http://seattlerb.rubyforge.org/

• http://rubyforge.org/projects/seattlerb

ParseTree is a C extension (using RubyInline) that extracts the parse tree for an entire class or a specific method and returns it as a s-expression (aka sexp) using ruby's arrays, strings, symbols, and integers.

Changes:

• 3 minor enhancements:
  • Added begin/rescue/ensure test.
  • Added blockpassargsandsplat.
  • Allow methods to be pulled from unparsed files.

• 1 bug fix:

  • Compatibility fixed across 1.8.

• http://www.zenspider.com/ZSS/Products/ParseTree/