ライブラリの動作を学習するためにテストを書く

TDDのパターンに学習用テストというものがあると『テスト駆動開発入門』に載っていた。

自分が作ったものではない外部のライブラリを使い始めるときに、動作を確認するために小さなコードを書く、ということは誰でもしていることだと思うが、その動作確認のためのコードをテストとして書く。

それによりライブラリのAPIに対する理解をコードに落とし込んで残しておけるので、曖昧な理解が減りそう。
正しい理解ができていればテストはパスする。

またライブラリのバグなのか、自分の使い方が悪いのか切り分けるのにも使えそうだ。
そういう原因がよく分からない状況になってしまったらテストを追加して追い込んでいけば良い。

また副産物として、ライブラリがアップデートされたときにその影響をテストするのにも使うことができる。

試しにamazon-ecsで学習用のテストを書いてみた。

# -*- coding: utf-8 -*-
require 'spec_helper'

describe "Amazon::ECS" do
  before(:all) do
    Amazon::Ecs.configure do |options|
      options[:aWS_access_key_id] = 'xxxxxxxxxxxxxxxx'
      options[:aWS_secret_key] = 'xxxxxxxxxxxxxxxxxxxxxxxxxxx'
      options[:associate_tag] = 'xxxxxxxxxxxxxxxxx-22'
      options[:country] = :jp
    end
  end

  describe "::item_search" do
    before(:all) do
      @res = Amazon::Ecs::item_search(
	    'Rubyレシピブック 第3版 303の技', {
		:response_group => 'Medium',
        :type=> 'title',
        :sort => 'salesrank',
	  })
    end

    it "リクエストが受け付けられること" do
      @res.should be_is_valid_request
    end
    it "リクエストにエラーがないこと" do
      @res.error.should_not be_nil
    end
  end
end

確かに使い方がよく分かるし、ちょっと値を変えてみたら挙動がどう変わるのかといったことも試しやすい。
これはいい。

ただ学習用なので基本的にあんまりがっつり書く必要はないと思う。
自分が満足行くとこまでで良いかと。

アップデートの内容次第では壊れちゃう儚いものだし、特に若くて成長中のライブラリを対象にするものなんかだとすぐに壊れそうだ。
なので取っておく資産と言うよりは学習のためのツールとしてガンガン使うというイメージ。

アップデートの影響テストという目的ではアプリケーション側のテストコードでカバーしたらいいしね。