EclipseプロジェクトをEGitでGitHubにPushする

『JUnit実践入門』の演習問題を、手を動かして解いてみようと思ったのは良いのだけれど、そのときEclipse上のコードをGitHub上のリモートリポジトリに登録するのに手間取った。まだ未整理の部分があるけれど、次に似た作業をするまで間がありそうなので、メモを残しておく。

なお、バージョン情報は下記の通り。

• Eclipse 3.8
• EGit 2.2

下記の手順で、GitHub上のリモートリポジトリso-c/junit-introduction · GitHub以下に、Eclipse上の複数プロジェクト（チュートリアル用、各章の演習用）を登録できた。ただ、コミットログに残っている通り試行錯誤していたから、不正確な部分があるかもしれない。

1. Eclipse上でプロジェクトを作成する。ここでは、"junit-practice"を使う。
2. 作成したプロジェクトのコンテキストメニューから、[Team] > [Share Project]を選択する。
3. "Share Project"ウィンドウが開くので、"Git"を選択して[Next]を押す。
4. "Configure Git Repository"ウィンドウが開くので、下記の通り入力する。
• 最初のプロジェクトでは下記を実行して、リポジトリを作成する。
1. "Repository"横の[Create]ボタンを押す
2. "Create a Git repository"ウィンドウが開くので、下記のように入力し、[finish]を押す。
• Parent Directory: /home/so_c/git
• name: junit-practice
• 2つ目以降のプロジェクトでは、"Repository"で作成したリポジトリを選択する。
5. "Configure Git Repository"ウィンドウのリストに作成したリポジトリが表示されるので、チェックし[finish]を押す。

これで、Eclipseのプロジェクトがローカルリポジトリで管理されるようになる。何かコミットしたとして、リモートリポジトリにPushするには、次の2種類の方法がある。空のリモートリポジトリを予め用意しておくこと。

• Push： プロジェクトのコンテキストメニューの[Team] > [Remote] > [Push]から使用する。EGitメモ(Hishidama's Eclipse Git Memo) 新規プロジェクトの作成方法を参照。
• Configure Push： プロジェクトのコンテキストメニューの[Team] > [Push to Upstream]から使用する。事前に設定が必要。EGit/User Guide - Eclipsepediaに書いてあると思うのだけれど気が付かず、端末からgit remote add
でリモートレポジトリ追加して、[Team] > [Remote] > [Consigure Push to Upstream]から設定してしまった。

なお、プロジェクトのルートをリポジトリのルートに対応させる場合は、4の手順が次のように変わるはず。通常はこちらの方をよく使うと思う。今回は、リポジトリ内で、チュートリアル・演習問題の各章を違うプロジェクトにしたかったから、1リポジトリ複数プロジェクト構成にした。

1. "Use or create repository in parent folder of project"をチェック
2. ローカルリポジトリの場所を入力し、[Create Repository]を押す (プロジェクトフォルダの親フォルダが既にリポジトリなら、不要のはず)
3. [Next]を押す

References

• EGitメモ(Hishidama's Eclipse Git Memo)
  
• 最低限おさえておきたいEGitの使い方について - メイクミラクル　～大逆転～
• EGit/User Guide - Eclipsepedia

"Object Calisthenics" (『オブジェクト指向エクササイズ』)

"Object Calisthenics" (『オブジェクト指向エクササイズ』) を読んだ。最初にルールだけを知ったときは、無茶を感じたけれど、そもそも何のためのルールで、各ルールがなぜ設定されているか、を知ったら納得できた。

"Object Calisthenics"のルールは、遵守すべきコーディング規約でも良い設計・コードのための原則でもない。オブジェクト指向のコンセプトを自分のものにして実践できるようにするためのエクササイズに使うギプスのようなものだ。それも、少なくとも自分にとっては、かなり強力なギプスだ。

ルールは全部で9つある。いずれのルールも、オブジェクト指向のコンセプトは知っている上で、実践に移すのを助けるためのものなので、かなり具体的。長くなるので、個々のルールには立ち入らないけれど、覚え書きを兼ねて（）内に私訳を付けておく。

1. One level of indentation per method（各メソッド、インデントは1段階）
2. Don't use the ELSE keyword（else句は使わない）
3. Wrap all primitives and Strings（プリミティブ型と文字列にはラッパークラスを作る）
4. First class collections（コレクション型にもラッパークラスを作る）
5. One dot per line（メソッドをチェーンさせない）
6. Don't abbreviate（略語は使わない）
7. Keep all entities small（クラスは50行以下、パッケージは10クラス以下を保つ）
8. No classes with more than two instance variables（インスタンス変数は2つまで）
9. No getters/setters/properties（ゲッター/セッターあるいはプロパティを使わない）

これらのルールは、いずれも凝集度を上げ結合度を下げ、最小化した責務を局所化し、情報隠蔽・ポリモーフィズムを実践を助けてくれる。1, 2はポリモーフィズムを推し進め、3, 4, 5, 9は問題領域外の情報を隠蔽し、6, 7, 8は責務の割り当てを最小化・局所化する。

その結果、再利用性もメンテナビリティも高いクラスになるので、保守・運用が容易になる。リーダビリティ・テスタビリティも上がるので、開発者にとっても嬉しい。

著者によると、100%これらのルールに従って20時間くらいかけて1000行ほどのコーディングすると、これまでの習慣（手続き指向）から抜け出せるとのこと。自分は割と本を読む方だけれど、どれだけ読んでも手を動かしていない内容は簡単に忘れてしまう。100%は無理そうだけれど、意識してみるつもり。

References

• Object Calisthenics
• オブジェクト指向できていますか？

unittestの実行方法

Python 2.7.3のunittestでテストを実行する方法。実行方法には2種類ある。

• コマンドラインインタフェース(CLI): テストモジュール名などを指定して実行
• テストディスカバリ: テストモジュール名のパターンを指定して実行

CLIは、特定のモジュールのデバッグに便利。ディスカバリはコミット前などの回帰テストに便利。

CLIでは次のように、モジュール名・クラス名・メソッド名のいずれかを修飾子込みで指定する。

$ python -m unittest test_library.test_module
$ python -m unittest test_library.test_module.TestClass
$ python -m unittest test_library.test_module.TestClass.test_method

空白区切りで複数のテストを指定することもできる。

$ python -m unittest test_library.test_module1 test_library.test_module2

テストディスカバリでは、サブコマンドdiscoverを使用する。下記コマンドで、project_top_directory以下の"test*.py"にマッチするテストファイルが実行される。

$ cd project_top_directory
$ python -m unittest discover

対象ディレクトリやテストファイル名のパターンを変更したい場合は、オプション-s, -p, -tを用いる。

• -s: テストモジュール検索開始ディレクトリ
• -p: テストファイル名のパターン
• -t: プロジェクトのトップディレクトリ

References

• 25.3. unittest — ユニットテストフレームワーク — Python 2.7ja1 documentation
• 25.3.2. コマンドラインインタフェース
• 25.3.3. テストディスカバリ