単体テストは、通常自動化されているが、手動で実行されることもある。IEEEは、どちらかが片方より優れているとはしていない。手動による単体テストではステップ・バイ・ステップの手順書を利用することがある。とはいえ、単体テストをする目的は、ユニットを分離し、その正しさを検証することである。自動化は、これを達成するための効率が高く、本項に記載されている多くの利点を備える。逆に、慎重に計画されていないと、注意を欠いた手動の単体テストケースでは、多くのソフトウェアコンポーネントを含む統合テストケースとして実行されて、その結果、全部でないにしても、大部分、本来単体テストで達成されるべき目標に達しない可能性がある。自動化アプローチを使用しながらも、独立効果を完全に実現するために、テスト対象ユニットやコード本体は、その自然環境の外のフレームワーク内で実行される。換言すれば、元々作成された製品または呼び出し元のコンテキストの外で実行される。そのような独立した形でのテストでは、テスト対象コードと他のユニットや製品内のデータ空間の間の不要な依存関係が明らかになる。依存関係は、その後、除去することができる。自動化フレームワークを使用しながら、開発者はユニットの正しさを検証するために、基準をコード内に反映させる。テストケースの実行時には、フレームワークのログ中に、基準に満たないテストが記録される。多くのフレームワークは自動的に失敗したテストケースにフラグを立て、まとめて報告する。障害の重症度に応じて、フレームワークは、後続のテストを停止する場合がある。結果として、伝統的に単体テストはプログラマに、分離され、凝集したコード本体を作成する動機づけとなる。これを常に行えば、ソフトウェア開発における健全な習慣がつくられる。デザインパターン、単体テスト、リファクタリングを組み合わせれば、最善の解決策が出るようになる。ユニット・テスト・フレームワーク.