June 2010 Archives

I've been working on this idea with autotest.

Here is the state machine that autotest currently uses:

Autotest starts by running all tests. When there is a failure, autotest reruns the failures until they're all passing. Once they're all passing, autotest reruns all tests to ensure you didn't break anything.

This last state transition from red to green is where I'd like to change things. Here is what I'm thinking:

I want to make a stack, a tree really, of failure paths. These paths will be defined by the autotest "flavor" that is running (vanilla, rails, rspec, etc.). Illustrated above is a fictional rails setup with failures. The top two boxes are the same scenario and run the same.

On the left is "feature development mode". (I'm not settled on these names.) In that mode, autotest would run all leaf nodes all the time. After getting testa to pass, the other test failures would rerun as well as moving up to running all of testx.rb to verify nothing else in test_x.rb is broken. This strategy is specialized to provide the absolute fastest feedback you can get with a minimal amount of extra tests run on any given pass.

On the right is "refactoring mode". In that mode, autotest would run all failures at the deepest stratum. After getting test_a to pass, autotest reruns the other failing test methods. Once they're all passing, it moves up one level and reruns the failing test files. This strategy is specialized to allow you to focus on fixing intentional breakage as you refactor or otherwise change a single point in your code.

The difference between the two is potentially subtle. I'm not entirely sure it is necessary at this point... but I need to run with both strategies in order to really tell.

What do you think? Is refactoring mode necessary? Is this entire thing overkill?

# of iterations = 100,000
null_time                                            =  0.01s
Time.parse(s)                                        = 22.64s
DateTime.parse(s)                                    = 43.75s
DateTime.civil(*Time.parse(s).to_a.first(6).reverse) = 35.22s

Unless you're doing geology or astronomy... try to stick to Time.

ZenTest provides 4 different tools: zentest, unit_diff, autotest, and multiruby.

ZenTest scans your target and unit-test code and writes your missing code based on simple naming rules, enabling XP at a much quicker pace. ZenTest only works with Ruby and Test::Unit. Nobody uses this tool anymore but it is the package namesake, so it stays.

unit_diff is a command-line filter to diff expected results from actual results and allow you to quickly see exactly what is wrong.

autotest is a continous testing facility meant to be used during development. As soon as you save a file, autotest will run the corresponding dependent tests.

multiruby runs anything you want on multiple versions of ruby. Great for compatibility checking! Use multiruby_setup to manage your installed versions.

Changes:

4.3.3 / 2010-06-17

• 2 minor enhancements:

  • Added options and removed pattern from Autotest::RCov
  • update_rubygems now deletes cached rubygems installs

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

• http://rubyforge.org/projects/zentest/
• ryand-ruby@zenspider.com

Here's a stupid little snippet:

def ENV.method_missing msg, *args
  msg = msg.to_s
  if msg =~ /=$/ then
    self[msg[0..-2]] = args.first.to_s
  else
    self[msg]
  end
end

Changes:

ENV["GEM_HOME"] = ENV["GEM_PATH"] = dir

into:

ENV.GEM_HOME = ENV.GEM_PATH = dir

The #to_s inside the setter changes:

ENV["BOOL"] = "1"

into:

ENV.BOOL = 1

Not terribly useful, but much prettier imo.

ZenTest provides 4 different tools: zentest, unit_diff, autotest, and multiruby.

ZenTest scans your target and unit-test code and writes your missing code based on simple naming rules, enabling XP at a much quicker pace. ZenTest only works with Ruby and Test::Unit. Nobody uses this tool anymore but it is the package namesake, so it stays.

unit_diff is a command-line filter to diff expected results from actual results and allow you to quickly see exactly what is wrong.

autotest is a continous testing facility meant to be used during development. As soon as you save a file, autotest will run the corresponding dependent tests.

multiruby runs anything you want on multiple versions of ruby. Great for compatibility checking! Use multiruby_setup to manage your installed versions.

Changes:

4.3.2 / 2010-06-02

• 1 minor enhancement:

  • Removed support for rbx builds.

• 2 bug fixes:

  • Removed 'preview' from version filter so I can test with 1.9.2
  • Put PATH tweaks at front of PATH

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

• http://rubyforge.org/projects/zentest/
• ryand-ruby@zenspider.com

Hoe is a rake/rubygems helper for project Rakefiles. It helps you manage and maintain, and release your project and includes a dynamic plug-in system allowing for easy extensibility. Hoe ships with plug-ins for all your usual project tasks including rdoc generation, testing, packaging, and deployment.

See class rdoc for help. Hint: ri Hoe or any of the plugins listed below.

For extra goodness, see: http://seattlerb.rubyforge.org/hoe/Hoe.pdf

Changes:

2.6.1 / 2010-06-02

• 2 bug fixes:

  • Fix up hoe to be happy when rubyforge is missing or misconfigured
  • Fixed dep tasks to deal with broken rubygems changes RF#27847 (mjwillson)

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

• http://seattlerb.rubyforge.org/hoe/
• http://seattlerb.rubyforge.org/hoe/Hoe.pdf
• http://github.com/jbarnette/hoe-plugin-examples

Don't call it "SEO"... call it what it really is: