TODO.txt

・各アクションが設定ファイルから受け取るパラメータのリストを、シナリオのパラメータと同様に、メソッドのパラメータから判断する。同じ処理でできるはずなので抽出する
・[案] zaffy help {action名} でアクションのパラメータに関する説明を出す
・[案] 実行時のログをすべて残す
・sqlのコネクションをプールして最後に切断する
・単体テスト
・ドキュメント、自動テストの実施、を含めたビルド手順をまとめる
・カンマ区切りで複数プリセットを適用できるようにする（プリセット名を明記したときも default プリセットが適用されるべきか）
・[案] 設定ファイルとは別に初期化シナリオという形でオプションを用意したほうがいいかも？
・通常起こりうるエラーメッセージの簡略化 (エラー発生原因の整理)
  - シナリオファイルが見つからない
　- yaml ファイルのパースエラー
  - シナリオの循環参照
  - アクション実行前のシナリオ内の template 変数展開 (静的アクションの実行)
  - アクション実行時の例外
  - filter 適用時の template 変数展開
  - assert 時の template 変数展開
  - assert の失敗

完了
・todateフィルターの作成（mysqlのdateカラムはdatetime.dateオブジェクトに変換されるはず）
・sqlアクションのdo_updateを作成(複数個のSQLを実行できるようにする)
・has_assert などの action 共通メソッドを create_action 時に inject する（継承はしない）
・assert で使う res のプロパティは全部、自前 __cmp__ を定義した比較用オブジェクトにラップする。（assert 失敗したときに期待値と実際の値を返せるように）
・customtests (json_equalなど) の失敗時にもログを残すようにする
・アクションで run を実行した時のレスポンスタイムを記録する
・AssertionErrorになったときに、どのアクションの何個目のassertで失敗したかを表示する
・AssertionErrorになったときに、チェックした変数の値を表示する
・アクションをインスタンス化するたびに action モジュールにメソッド追加するのはあほらしいので、action_klass をメモ化しておく
・action._run の中で、実行が終わったら即結果を wrap するのではなく、assert するとき（variables を定義するとき）にだけ wrap するようにする。（他のactionから結果を参照するときにややこしいことになるので）
・1回の assert ごとに cmp_log をクリアするようにする。じゃないと他の assert の比較結果が残ってしまうので
・シナリオファイルはできるだけシンプルにしたいので、以下のようにトップレベルがリストで
　アクションをずらずと並べるようにしたい。ただし、その場合、ドキュメントを記述できないので
　１要素目を全体のドキュメント、２行目以降の文字列要素は次のアクションの説明、という風に解釈しようか？
　あるいは、actionのなかに desc などの要素を作る（こっちの方がすっきり？）
　 - 結果の確認テスト
   - action: http.get
     desc:
      ...
   - action: sql.select
      ...
・アクションとして使用可能なものと、jinjaテンプレート内で
　使用可能なグローバルオブジェクトを一緒にしても良いかも。
　例えば、file アクションで do_read という staticmethod を定義したら、
　それは <<file.read("hoge.txt")>> という形で使用可能にする、とか
・↑そうすると、const アクションを作成して、定数定義も可能になりそう。
　const の actionインスタンスに対して値を set すると、その値はクラス変数にセットされて、
　staticmethodから参照できるようになる
・定数を定義してHTTPパラメータやSQLで使用できるようにする
・アクション実行時のパラメータを jinja で展開できるようにする（文字列の場合は直接、リストや辞書の場合はそれぞれの中身を再帰的に置換していく）
・importアクションの作成
・パラメータ名が +hoge のように + から始まる場合に python 変数として展開した値を代入する
・各シナリオごとに設定の上書き、リセット。（preset機能の実装）
・preset機能とデフォルトパラメータ機能が競合してる
・envの作成（環境変数を参照する用）
・require の path 変数を解釈する際に、内部で環境変数を展開しているが、シナリオの方で env を使うようにする
・zaffy.yml ファイルを作って、そこでアクション単位のパラメータ指定や const, preset の定義などをできるようにする。
・zaffy.yml で定義したアクションごとのパラメータは、起動直後に各アクションの classmethod init(options) に渡す
・shellアクションの作成
・httpアクションに受け取ったデータを直接ファイルに保存する save メソッドを用意する。巨大なファイルを受信する際にメモリに保存してると厳しいので。（response.iter_content を使えばよい）
・file アクションの作成
  - read, copy, remove, move, exists, readable, writable, executable, size, created_date, updated_date, stats
・同一アクション内で必要なパラメータが異なるメソッドがある場合に、ActionParamSetting で指定できないのをどうにかする。メソッドごとに required とか optional を分けるか
・各アクションのメソッドの必須・オプションパラメータを inspect.getargspec で取るようにする＞ActionParamSetting の廃止
・アクションのパラメータチェック用の便利メソッドを用意する（任意、必須など）
・sshアクションの作成
・scpアクションの作成
・時刻操作用のクラス作成
  - now
  - 現在時刻から1時間前の datetime を取得等
・require するときに外部シナリオに対してパラメータを渡す、結果を受け取る方法
・各アクションの classmethod に before_all, after_all を用意する。シナリオの読み込みが完了したときに before_all, 全シナリオの実行が完了したら after_all が呼ばれる。引数に全アクションオブジェクトを渡したりする？
・csvフィルターを追加（できれば任意のセパレータで解釈できるもの）
・action の動作確認用に REPL を用意する
・結果出力機能の作成
・結果フィルターを作成する action: と同じ階層に filter: を作成して result に入れる
  (現状の assert の中で変数入れなおすのはやめる)
・require した先での assert 失敗や実行時例外（パラメータが足りない）の発生時に、
　どのシナリオで失敗したか分かるようにする（現状は require 元のファイル名しか表示されない）
・cursesモジュールを使って色付きで表示したい
→coloramaで実現できた
・const, preset などグローバルな情報を保持するものについては、1シナリオ実行するごとにリセットする
→無理やり対応
・sql アクションが drivers を読み込むのに失敗した際に、エラーメッセージを出す
・require.repeat で繰り返し実行した際、大量のアクションがメモリ上に残ったままだと
　メモリ不足で問題が起きる可能性がある（require, scenariorunner に何らかの解放手段が必要）
  →require は repeat であっても、実行する毎に参照が消えるので問題は無さそう

保留
・sqlアクションでファイルからsqlを読み込んで実行する機能を追加
→自前でsqlファイルをパースできないと駄目
・SQLアクションにxlsxファイルからデータを読み込んでinsertできるメソッドを追加する
・「シナリオディレクトリ」をコマンドのオプションで定義する（requireするときのトップディレクトリ）
→import用のディレクトリなどは const か env で指定して欲しいが、import_path 的な設定を用意するか
・require でシナリオを読み込むのはいいが、requireされる側のアクションが単体で実行されると困る場合がある
  （シナリオファイルの形式も要検討）
  → 案1: ディレクトリ指定された場合は *Test.yml のファイルだけ実行するようにする
  → 案2: require されるファイルは別ディレクトリに置いて使ってもらう
・パラメタライズテストをできるようにする？
→やるとしたら require.repeat

却下
・各アクションの設定の自動読み込み
→アクションごとに設定ファイルを作るのは面倒なので。
・各アクションに、before_{method} アクション実行前に呼ばれるコールバックを用意する。主にパラメータのチェック。
→preset があるため、アクション実行前にならないとパラメータが確定しない
・webmockアクションを作成する。別のアクションよりも前に起動すると別スレッドで web server を起動して、指定したパスに対して、任意のレスポンスを返す。リクエストが期待したものかどうかをチェックする
→これはテストクライアントがやるべき範疇を超えている


Python2.7を使う理由
        python 2.4 (try..finally が使えない)
        python 2.5 (except ... as ... が使えない)
        python 2.6 ({x:y for ...} が使えない)