python code reading#10

python code reading#10に参加しました。取り急ぎまとめます。

• heapq で学ぶヒープの実装とその用途 (森本哲也さん)
  • 資料
  • PyMOTWの話。翻訳の話。

• Pythonのテスト手法とテストコードを読む(柴田 淳さん)
• テストの利点
  • 開発と平行してバグを発見できる
    • プログラムを部品レベルで品質管理
  • プログラムの修正、リファクタリングがしやすくなる
    • class分割、アルゴリズム
  • 品質管理を自動化できる
    • 確認の手間を省ける

• pythonとテスト
  • Pythonのテスト手法
    • doctest
      • ドキュメンテーション文字列にテストを書く
      • テスト用コードが使い方の説明になる
        • python3.0以降だとlibrary moduleだと6つくらい。排除される傾向、JUnitへ
    • UnitTest
      • JavaのJUnit譲りのテスティングフレームワーク

• • COOKIE.py
    • 辞書ライクなCookiiオブジェクトを提供
    • httpdのヘッダとCookieオブジェクトを相互変換

• • ">>>"文字列を見つけてテスト
  • 説明っぽいが実はテスト。Doc書きながらTestがかける

• • DOCTESTの利点
    • 手軽
      • シェルの結果をぺたぺたはれる
    • DOC=TEST
    • 多くの機能をテストとして木jつつ
    • きれいなコード=DOC

• • 冗長
  • 特に継承したクラスのテストに弱い（コードが冗長になる)
  • オブジェクト生成を伴うテスト
  • 環境整備を伴うテスト
    • データベース接続、Web
    • 複雑なテストに向かない

• • UnitTest
    • Cookie.pyはユニットテストも装備
    • Set.py
      • Pure Pythonなset型
    • ユニットテストの強みを生かしたテストをしている

• テストとカバレッジ（網羅率）
  • 2007年のデータ(@O'reilyのブログ)
  • カバレッジ
    • ソースコードに対するテスト実施
  • 測定の指標はいくつかある
    • 命令、分岐、条件レベル

• Pythonは？
  • Python3.0(2.6)の時点でテストを強化

• カバレッジの二つの側面
  • 作る人
    • 開発効率の向上
    • 安心感
  • 使う人
    • クオリティの判定
    • 安定度の判定

• テストを始めるには？
  • まずはdoctestから
    • 慣れが大事
    • カバレッジ100%を目指さない
  • 他のテストコードをよく読む
    • フレームワークを始める前にテストコードを読む
      • 開発者の本気度がわかる、フレームワークの構造がわかる
  • ツール、テスティングフレームワークを使う
    • nose,pytest(by pypy)

• テストが書きづらい=リファクタリング開始のサイン
• 一つのテストパッケージをつくる感じ
• カバレッジを上げるには？
  • TDDを使いましょう。
• テストを作っていて自分がいやなやつだと思いません？
  • 逆に見つけてラッキーと思うといいのでは？
• カバレッジ表示するツールありますか・
  • たくさんあります。渋川さんが作っていた気がします。