ユニットテスト
ユニットテスト
単体テスト(ユニットテスト)は、プログラムを構成する比較的小さな単位(ユニット)が個々の機能を正しく果たしているかどうかを検証するテスト。関数やメソッドがそのテストの対象となる。プログラムが全体として正しく動作しているかを検証する結合テストより断然早い段階で行われる。
利点
実装時にテストを行うため、問題の特定や修正が容易になる。
実装した人がその直後におそらくテストケースを実装するため、妥当性の高いテストケースを残せる。
欠点
実装者に負担。
実装者自身にもある程度の知識が要求される。
当然時間を取られる。また時間の関係でテストが省かれた場合、プロジェクト全体でテストが省略されたり実装されてたりと、バラバラになる可能性がある。
種類
ホワイトボックステスト
テスト対象のメソッドor関数の内部に着目。条件分岐や繰り返しなどの各部分を確実にテストする。
ブラックボックステスト
テスト対象のメソッドor関数の入出力に着目。期待する機能を満たしているかをテストする。
Dependency Injection 依存性の注入
まずここで概念を掴んで
qiita.com
このページでもう少し掘り下げると、すんなりと概要が頭に入ってきます。
itpro.nikkeibp.co.jp
ざっと掴んだ感じ、、
Aが必要とするBというものを、A内に含めずに、実行時に動的にAをBに渡そうという思考(多分)
似た挙動をAで使用する時、渡すものをBではなくCにすれば動くようにしておけば、実装も楽だしどこを変更すれば良いかもわかりやすく、なおかつ使い回しも可能でいいよねって感じ?(使い回しは副産物で、使いまわせるぐらい機能が分離されていてメンテナンスを含めて使用が行いやすいってことかな)
IDのメリットデメリット
コードが簡潔になり開発期間が短くなる <-> スタートアップ時のコード量(仕事量)が増える
階層構造が綺麗に分離された状態になる <-> クラスやファイルがたくさん生成される
特定のフレームワークへの依存が少なくなるため、柔軟になる
git 随分前にforkしたローカルリポジトリをfork元の最新の状態に更新する
-
-
- 追記 2017/3/29---
-
このサイト様がわかりやすかったです。
【備忘録】Fork元の変更を自分のリポジトリに反映する - 『入る学科間違えた高専生』の日記