05.17.08 - 11:36pm
I just brought a new project into the world of autotest. I’m not using the Leopard FSEvents “fix” because it’s not necessary (note the sleep and add_exception calls below). I am using the fun and helpful sound plugin, but not the playlist version of that plugin. Here’s my .autotest file.
Category: testing, ruby, ruby on rails, Mac, tools | Tags: | 1 Comment »
05.16.08 - 04:42pm
I’ve seen a few Rake tasks for Rcov that work OK, but which fail in an interesting way (if you care about coverage): they give your coverage metrics an unexpected boost if you have 0% coverage in one or more source files.
Huh? Exactly. If you have 500 source files, and your test suite only requires […]
Category: coverage, testing, ruby, ruby on rails, tools, Uncategorized | Tags: | Be the First to Comment »
08.04.07 - 04:21pm
I’ve written before about tips for offshoring. One specific thing I said to watch for is the bait-and-switch of talent: during the sales process you’re shown rockstars, but the real code you get is written by clueless newbies. When you set up a project such that you’ve minimized the cost per hour of development, but […]
Category: management, java, testing, offshoring, outsourcing, sql, labor, humor | Tags: | 7 Comments »
08.02.07 - 08:37pm
From what I’ve seen, Rails’ weakest features lie in the way it prepares the test database and test data, and Ruby’s Test::Unit isn’t much better than the awful but ubuiquitous JUnit that Java developers are accustomed to. I set out this week to impose my preferences on Rails in this area, and that took some […]
Category: ruby, java, testing, ruby on rails, postgresql, databases, sql, architecture | Tags: | 5 Comments »
07.11.07 - 01:26pm
Coverage tests in Ruby (with rcov) are less strict than in Java (with EMMA), so watch out - 100% coverage is easy to attain but not as meaningful.
Category: testing, coverage, java, ruby, tools | Tags: | 3 Comments »