はじめに
システム開発の際は、言葉の定義を確認する場面が多々ありますが、「単体テスト」について若手に質問を受けたので共有しておきます。
単体テストには、「ソフトウェアの単体テスト」という意味で呼ぶ会社もあれば、「機能の単体テスト」という意味で呼ぶ会社もあるので注意しましょう、という話です。
今回の話の工程
システム開発工程のテスト工程は、単体テスト・結合テスト・システムテスト（総合テスト）と呼ばれることが多いのですが、「単体テスト」については、「ソフトウェアの単体テスト」という意味で呼ぶ会社もあれば、「機能の単体テスト」という意味で呼ぶ会社もあります。
割合としては、機能単体テストのことを「単体テスト」と呼びことが多いとは思いますが、これらの違いも含めて整理しておきたいと思います。
ソフトウェア単体テスト（ユニットテスト）
「単体テスト」という言葉を、「ソフトウェア単体レベルのテスト」という意味で使う会社があります。
会社によって、
・ソフトウェア単体テスト（略して、単体テスト）
・ユニットテスト（略して、UT）
などのような呼び方があります。
（私の経験上は、ソフトウェア単体テストは「ユニットテスト」と呼ぶことが多いと思います）
ソフトウェア単体テストのテスト観点について
それぞれのテストの違いを理解するために、テスト観点についても補記しておきます。
ソフトウェア単体テストは、その名の通り、ソフトウェア単体での品質を確認するためのテストで、実装の元となった詳細設計書からテストケース（テスト条件・期待値）を設定して確認をしていきます。
「ソースコードからテストケースを洗い出せば、全ての条件が網羅できるんじゃないの？」と感じるかもしれませんが、詳細設計書からの実装漏れを検出できるように詳細設計書からテストケースを設定します。
なお、テストケースについては、テスト条件の抜け漏れ防止や、テスト結果（期待値）の認識違い防止のためにデシジョンテーブルなどを用いて整理することが多いと思います。
出典： type『開発したシステムをテストしよう！テスト工程を効率よく着実に進めるためのポイント』
こういった表を用いてテストケースを整理した上で、ソースコードと突き合わせて抜け漏れ確認（つまり、カバレッジ確認）を行います。
定量的なカバレッジの測定をするために、JavaであればJUnitでテストコードを実装することが多いと思います。例えば、以下の例では、Color1.java(赤線)のカバレッジが86.7%（合計命令数が15に対してカバー命令が13）なので未実施のものがあることがわかります。
出典： ITSakura『Java Eclipseでカバレッジを取得するサンプル』
機能単体テスト（ソフトウェア結合テスト）
「単体テスト」という言葉を、「機能単体レベルのテスト」という意味で使う会社があります。
会社によっては、
・ソフトウェア結合テスト
・機能単体テスト（略して、単体テスト）
・単機能テスト
などのような呼び方がありますが、私の経験上では、こちらを「単体テスト」と呼ぶことが多いような気がします。
基本設計書で記載されている単体機能となるので、
画面仕様： １画面
帳票仕様： １帳票
バッチ仕様： 1バッチ（ジョブ）
API仕様： 1API
といったように、各機能のドキュメント単位に検証をしていきます。（バッチの場合は、当段階で「ジョブ単位」での検証を行い、次工程の結合テストにて「ジョブネット単位」の検証を行う）
ソフトウェア単体テストのテスト観点について
それぞれのテストの違いを理解するために、テスト観点についても補記しておきます。
機能単体テストは、その名の通り、機能単体での品質を確認するためのテストで、機能単体の仕様を記載している資料（つまり、基本設計書）を元にテストケースを設定して確認をしていきます。
以下のようなテスト仕様書と、前述のデシジョンテーブルを組み合わせたりして、テスト条件の網羅性を確認します。
出典：SHIFT『テスト仕様書の書き方～テストケース作成のポイント～』
おわりに
ということで、「単体テスト」については、ソフトウェア単体テストなのか、機能単体テストなのかの言葉の定義は注意しましょう。
なお、結合テストについても内部・外部といった曖昧さを含みますが、新入社員研修などで教育を受ける基礎知識なので、今回は割愛します。