Archive

Archive for the ‘Test Driven Development’ Category

Autospec with custom directory/file names

January 17th, 2010 No comments

Autotest is a great time-saver when doing BDD (or TDD for the less-enlightened, lol).  Autospec seemlessly integrates Rspec.  However, if you don’t use the expected “spec/*_spec.rb” structure, autotest will not find your specs – or examples, as I call them.

It is very easy to use whatever structure you want using the following steps:

Telling Autotest to use Rspec as the test runner

The first thing you want to happen is for Autotest to use Rspec as the test runner.  This usually happens automatically using autospec, which tests for the presence of the spec directory.  Since we do not want a spec directory, we must tell explicitly tell Autotest to do this.  So:

Step 1: in your project directory create a file autotest/discover.rb with the following line:

Autotest.add_discovery { "rspec" }

Teaching Autotest about our custom directory structure

In order to do this, we have two options.  If we want to use the same structure for all our projects, we can put a file in our home directory, otherwise we can add custom files to each project directory.

Step 2: create a file .autotest with the following code:


class Autotest::Rspec < Autotest remove_method :consolidate_failures def consolidate_failures(failed) filters = new_hash_of_arrays failed.each do |spec, trace| if trace =~ /\n(\.\/)?(.*example\.rb):[\d]+:/ filters[$2] << spec end end return filters end remove_method :add_options_if_present def add_options_if_present # :nodoc: File.exist?("examples/spec.opts") ? "-O examples/spec.opts " : "" end end Autotest.add_hook(:initialize) {|at| %w{.git .svn .hg .swp .DS_Store ._* tmp}.each do |exception| at.add_exception(exception) end at.clear_mappings # take out the default (test/test*rb) at.add_mapping(%r%^(examples|third_party)/.*_example.rb$%) { |filename, _| filename } at.add_mapping(%r%^lib/(.*)\.rb$%) { |_, m| ["examples/#{m[1]}_example.rb"] } at.add_mapping(%r%^examples/(example_helper|shared/.*)\.rb$%) { at.files_matching %r%^(examples|third_party)/.*_example\.rb$% } #nil }

Let’s take it piece by piece:


def consolidate_failures(failed)
  filters = new_hash_of_arrays
  failed.each do |spec, trace|
    if trace =~ /\n(\.\/)?(.*example\.rb):[\d]+:/
      filters[$2] << spec
    end
  end
  return filters
end

This method tells Autotest which test files have failed by pulling the file names out of the test output. Since autospec looks for *_spec.rb files, it will not find our custom files. I use *_example.rb filenames, so you should replace that part of the regex with whatever you use.


def add_options_if_present # :nodoc:
    File.exist?("examples/spec.opts") ? "-O examples/spec.opts " : ""
  end

This method tells Rspec where to find an option file. Again, replace the details with whatever you use.

In Autotest.add_hook(:initialize):

  %w{.git .svn .hg .swp .DS_Store ._* tmp}.each do |exception|
    at.add_exception(exception)
  end

This tells Autotest to ignore certain files that are irrelevent to testing

at.clear_mappings

This tells Autotest not to use any other mappings i.e. the default test/test*rb, or Rspec’s spec/*_spec.rb

at.add_mapping(%r%^(examples|third_party)/.*_example.rb$%) { |filename, _|
  filename
}
at.add_mapping(%r%^lib/(.*)\.rb$%) { |_, m|
  ["examples/#{m[1]}_example.rb"]
}
at.add_mapping(%r%^examples/(example_helper|shared/.*)\.rb$%) {
  at.files_matching %r%^(examples|third_party)/.*_example\.rb$%
}

This is the meat of the customization. It tells Autospec, based on which files have changed, which tests to run. Replace my regexes with your custom matches.

The end

Once you have added both these files, running autospec from your project directory will work as it should!

Only running unit tests in Xcode if the build was successful

August 14th, 2009 2 comments

My workflow in Xcode is typical TDD – write a test, run the tests, write some code, run the tests…  I set up a “Run Script” build phase, so that every time I build the tests, they are automatically run.  The only problem is that the “Run Script” happens whether the build was successful or not.  So, I try to build and fail, and then the same exact tests that I already ran, automatically run again – while I sit there and wait.

The solution turned out to be very simple.  “Run Script” build phases in Xcode can have input files and output files.  The phase is only run if some input files were more recently modified than some output files.  Thus, if we set the input file to be the test executable, and the output files to be all the source files, then the tests will only run if the build is successful.  It will look something like this when set up:

Conditional Run Script Phase

Why Behavioral/Test Driven Development?

March 20th, 2009 No comments

I’m so clear on the “how” of BDD.  What I haven’t been connected to is the underlying motivation, the first principles from which all the techniques flow.   So I decided to start collecting them in one place (here, lol)…

  • Driving is the key word.  Emergent Design is the result Testing is a bonus.  The real juice is that the specifications actually drive the code to achieve its objective as simply as possible

Writing code after vacation

March 19th, 2009 No comments

It’s amazing.  I read about the poor maintenance programmers who will spend way more time working with my code than I will writing it.  About how important it is to keep the code clear so that they can recreate what I was thinking.  It makes total sense.  What freaks me out is how often I benefit from readable code.  I just got back from a four-day weekend in LA and I’ve settled back into my test driven code like a favorite comfy chair.

Me: “What the heck does this class do?!”

The tests:

  • BOOST_AUTO_TEST_CASE( shouldThrowOnInvalidDBInfoPassedToConstructor )
  • BOOST_AUTO_TEST_CASE( shouldConnectToDBViaConstructor )
  • BOOST_FIXTURE_TEST_CASE( shouldConnectToDBViaConnectFunction, NotConnected )
  • BOOST_FIXTURE_TEST_CASE( shouldThrowIfPassedBogusServerCredentials, NotConnected )
  • BOOST_FIXTURE_TEST_CASE( shouldThrowOnSelecting, NotConnected )
  • BOOST_FIXTURE_TEST_CASE( shouldSelectDB, Connected )
  • BOOST_FIXTURE_TEST_CASE( shouldThrowIfInvalidDBSelected, Connected )
  • BOOST_FIXTURE_TEST_CASE( shouldThrowIfSelectingInvalidDB, Connected )

Me: “Ok, right.  Now I can get back to work.”

Categories: Test Driven Development Tags:

TDD: A Practical Guide by Dave Astels

March 8th, 2009 No comments

I was attracted to Dave’s work after seeing him in some Google videos.  You can tell right away that he has TDD in his bones.  And, even better, he seems to be very practical and light on the dogma.  Here are some of the points that I found illuminating:

  • Programmer tests – define what it means for the code to work, different from unit tests (test that the code you’ve written works)
  • Comments – if they are required, consider that the code is not clear enough.  Valid reasons are todo placeholders, use of unusual algorithms (cite reference if published), performance tuning (so maintainers don’t undo), and class descriptions
  • TestCase (unit test framework classes) – for sharing fixtures, not for conceptual grouping.  This is great, so many basic tutorials make it seem like you should have one TestClass per ClassToBeTested, which creates duplication for member tests with partially overlapping setups.  Dave says: split them up into separate TestCases – so obvious, so perfect!
  • Keep test methods small, ultimately one-assert-per-test – so much clearer.  Instead of writing 4 asserts on 3 different objects, refactor into 3 test methods with a common fixture
  • Test boundary conditions early – easy way to get started (e.g. null and INT_MAX)
  • External resources (e.g. databases) – don’t test against, use mocks
  • Add a main to test cases so you can run them individually from a tool
  • Mocks – many benefits and uses.  Two I always like are to test unusual/exception events and as a placeholder until classes are actually implemented

Holy crap!  I just got to the example project.  This is the book I’ve been wanting to read since I started programming.  The example is an end-to-end TDD project.  He goes from project vision on through as if you’re coding together.  Most other books use toy implementations that leave out all the thorny parts – the GUI, the flexion of the model as requirements change.  I’m still reading, and I can’t wait to get through this project!!!

Categories: Test Driven Development Tags: ,

windows 7 product key

windows 7 product key

windows 7 key generator

windows 7 key generator

free winrar download

free winrar download

winzip activation code

winzip activation code

free winrar

free winrar

winzip free download

winzip free download

winrar free download

winrar free download

winrar download free

winrar download free

winzip free download full version

winzip free download full version

windows 7 activation crack

windows7 activation crack

windows 7 crack

windows 7 crack

free winzip

free winzip
\n