テスト方法はm6uさんのサイトを参考にするのが良いと思います。
ユニットテストは手で行うテストを単純にコードで書き、それ以降自動で実行できるというものです。
なので、手で行うテストのリクエスト情報をロジックで書くことになります。
※これが結構大変
ユニットテストは作成するのに、通常のテストの倍ぐらいの工数が掛かります。
テスト用のロジック自体があっているかの検証が必要になるからです。
その辺は問題ないのでしょうか?
1つ修正すると、違うところでバグが発生するという状況です。
デグレのことを言っているのであれば、影響調査に時間を割く方が工数は掛からないと思います。
結構勘違いしている人がいるのですが、ユニットテストの導入時の初期工数はかなりでかいです。
※再テストの工数はかなり減りますが、仕様変更があった場合、対象のテストロジックも全て変更になることに注意して下さい。(ユニットテスト用のコードメンテナンスの工数が余計に掛かる)
少し長くなったので追記:
個人的な意見になってしまうのですが、
ユニットテストは仕様のテストではなく、プログラムが想定する結果を返却するかの観点で行います。
※同じように思えますが、全てのクラスが期待通りの結果を返却をしたら、仕様が満たされるって感じです。
なので、ユニットテストの単位はクラス単位に行います。(機能単位ではありません)
導入になれる為にも、軽い共通のクラスから行うのが良いと思います。(引数が少なくて、結果が分かりやすいもの)
次にその他のmodelクラスですね。(FuelPHPで自動生成されているものは除外)
次に拡張しているCore系をやって行く感じが良いかと。。(テスト観点とかが難しい)
自分の場合、controllerには導入しないですね、
結局画面からのリクエストが正しいかなどで、画面を動かすことになるので。。。(二度手間)
model内で直接リクエスト情報を取ってたりしたら、そのクラスについては導入はあきらめた方が良いと思います。
(modelが画面に依存している状態だから、controllerと同じ状態※FuelPHP本来の考え方ならありえないはずです、、、)