UnitTestでのprivateメソッドとの向き合い方

privateメソッドのUnitTestについて、下記のような扱いがあると思う。

• スコープを（例えばprotectedに）拡張する
• 直接間接を問わず、リフレクションなどを活用してテストする

これらに対して、ずっと何か違和感を覚えていた。
実践JUnitでちょっと触れられている箇所があって、自分なりの読み解きで何となく向き合い方が腹落ちしたので書いておく。

• UnitTestはメソッドのテストではなく、そのふるまいのテストにより重きが置かれるべき
• privateメソッドは実装の内部詳細であり、その変更はふるまいに影響をあたえるべきではない

上記の前提を考えると、基本的にはpublicスコープに対してのテストで十分になりえるはず。

そのクラスのふるまいであるなら少なくともパッケージ以上にスコープが（テストのためではなく）拡張されることに違和感はない。
そうでないならば別のクラスに切り出すようなふるまいなのかもしれない。

結局のところ、privateメソッドの詳細に踏み込んだテストが必要になった時は、設計に何か問題がある可能性が高いということなのだと思う。

実践 JUnit ―達人プログラマーのユニットテスト技法

追記

@t_wada さんにTwitterで参考記事を教えていただきました！

qa.atmarkit.co.jp

追記その２

@backpaper0 さんのブログ

backpaper0.github.io

AWS CLIの導入

概要

aws cli をMacで使えるようになるまで。

手順

pythonのインストール

$ python --version

はいってた

aws cli のインストール

$ curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
$ sudo python get-pip.py
$ sudo pip install awscli --upgrade --ignore-installed six

インストールの確認

$ aws --version

認証の設定

aws configure set aws_access_key_id {IAMユーザのアクセスキーID}
aws configure set aws_secret_access_key {IAMユーザのアクセスキー}

• ~/.aws/credentials に設定される

おまけ

Bundled Installer を使った手順

最初こっちでやってみたけどpipでやるほうが一般的みたい。

$ curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"
$ unzip awscli-bundle.zip
$ sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws

Installing the AWS Command Line Interface - AWS Command Line Interface

アンイストール手順

$ sudo rm -rf /usr/local/aws
$ sudo rm /usr/local/bin/aws

Uninstalling the AWS CLI - AWS Command Line Interface

Pythonの導入

virtualenvで環境作ってpipが一般的らしい

Virtual Environments — The Hitchhiker's Guide to Python Pythonの仮想環境を構築できるvirtualenvを使ってみる - Qiita

メリットとしては下記。

• 複数バージョンの利用
• ライブラリ環境の独立性
• 環境丸ごと他にコピーしたり入れ替えられたりする

参考

OS X EI Caption(10.11.1)でAWS CLIのインストールエラー - Qiita

GitHubでtagをmasterにする

概要

GitHub上のOSSをフォークして開発したい。
でも、フォーク元のmasterではなくtagから派生させたい。
ので自分のリポジトリ（フォーク先）ではtagをmasterにする手順。

手順

リポジトリをForkする

GitHubから普通にForkするだけ

tagを開発ブランチとしてpushする

cloneした後、tagを確認する

git tag -l

tagからブランチを作成する

git checkout -b ${ブランチ名} refs/tags/${タグ名}

作成したブランチをpushしておく

masterブランチを削除する

GitHubではdefaultブランチがmasterになっている。
そしてdefaultブランチは削除できないのでGitHubの画面から変更する。
変更先はtagから作成したブランチ。

[settings]→[branches]→[Default branch]

masterを削除する
※削除せずにリネームでも良い

git push origin :master

tagから作ったブランチをmasterにする

ローカルのブランチ名変更

git branch -m hoge master

リモートに反映。

git push origin master

GitHubでdefaultブランチをmasterに変更する。
実質的には別名同ブランチが存在する状態になるので、不要なブランチ等は必要に応じて削除する。
（ローカルもリモートも）

参考

• gitでタグをチェックアウトする。
• ローカルとリモートのブランチ名を変更する
• Githubのmasterブランチを削除して、masterを置き換えた (^o^;)

Rubyのto_yamlを使ってyamlの書き方を思い出す

サンプル

require 'yaml'

users = [
  {'name' => 'yamada', 'score' => 90},
  {'name' => 'sato', 'score' => 30},
]

puts users.to_yaml

出力結果

---
- name: yamada
  score: 90
- name: sato
  score: 30

リポジトリ名が変わってしまった！そんなとき #git

概要

リモートリポジトリの名前が変わってしまうと、ローカルリポジトリのfetch/push先がなくなってしまうので、その対応。

とどのつまり、リモートの向き先が変わるだけということなのだ

今の向き先を確認

git remote -v
origin  git@github.com:hoge/old-name.git (fetch)
origin  git@github.com:hoge/old-name.git (push)

向き先を変更する(originの場合)

git remote set-url origin git@github.com:hoge/new-name.git

変更を確認する

git remote -v

参考

http://qiita.com/8mamo10/items/a7be3e146a1197c6f1c0 http://d.hatena.ne.jp/wats/20100910/1284261816

オプティマイザが吐き出したクエリを確認する #mysql

概要

オプティマイザが実際に組み立てたクエリを確認する方法です。
実行結果や取得結果が期待通りにならない時など、ヒントが隠されているかもしれません。

手順

EXPLAINの後ろにEXTENDEDを追加するとWARNINGとして、オプティマイザが吐き出したクエリが出てくる。

mysql> explain extended
    -> select * from hoge;

mysql> show warnings

TIPS

• <cache> みたいな文字列は消さないとシンタックスエラーになる

参考

• MySQLのwhere ~ inとサブクエリの組み合わせで悩んだ話 | KentaKomai Blog

git コマンドのブランチ名などを補完する #git

git-completion.bashを導入するとgitコマンド補完されるようになるのでとてもうれしいヽ(=´▽`=)ﾉ

https://github.com/git/git/blob/master/contrib/completion/git-completion.bash

参考

http://qiita.com/snaka/items/4b0437a32da832d2e0db