ユニットテストの一般論になってしまいますが、基本的にはクラスのメソッド単位での実行結果が設計通りか確認するためのものですので、あくまでも設計書通りにコーディングできているかの確認でしかありません。主に限界値チェックや条件判断のパターン網羅を楽にできると考えた方がいいでしょう。
このメリットとして、コードを修正した場合の確認が楽であること(同じテストを再度流すだけで済む)が挙げられます。もちろん、修正というのがメソッドの仕様を変えるものではない場合に限ります。
よって仕様の抜けなど設計に漏れがあった場合、ユニットテストでは確認できませんし、仕様が変更になった場合関連するテストコードも書き直す必要があります。
デメリットとしては、作業工数がそれなりにかかることです。単体テストのパターン網羅などの工数は一度テストコードを書けば次回からはテストを流すだけになりますが、メソッド一つ一つについてテストコードを書きますので、単純に通常の2倍近くの工数を見込んだ方がいい、ということになります。
またテストコードを設計するのは仕様書からテスト仕様書を起こすのと同じセンスとスキルが必要です。
あと、ユニットテストといっても万能ではないので、メソッド単体のテストなどには向きますが、ユーザインターフェースのテストやシステムテストなどには不向きです。
このあたりはユニットテストについて調べてみると、より詳しい解説のあるサイトなどが簡単に見つかりますので、ご自身で勉強されることをお勧めします。