単体テスト(ユニットテスト)とは
ドライバー テスト対象のコードを呼び出すコードを代替します。 スタブ テスト対象のコードが呼び出しているコードを代替するもので、呼び出し先のコードがまだ作成されていない場合などに使用します。 単体テストでは、これらの仕組みによって、テスト対象の関数・メソッドをプログラムの他の部分や外部のコードから隔離して徹底的に検証できるという利点があります。反面、これらの付加的なコードを作成したり管理するための負荷は、プロジェクトの規模が大きくなるほど、また改修を重ねて期間を経るほど増大します。 単体テスト(ユニットテスト)の種類テストケースを作成する際、何に着目するかという観点から見ると、単体テストは大きくホワイトボックステストとブラックボックステストに分類できます。ホワイトボックステストは、テスト対象関数またはメソッドの内部構造に着目し、いっぽう、ブラックボックステストは、テスト対象関数またはメソッ
シェルスクリプトにxUnitを使ってみる - Qiita
今回はタイトルの通り、shUnit2について取り上げたいと思います。Batsは気になるから別の機会に。 shunit2とは shUnit2は前項でも書いたとおり、シェルスクリプト向け自動テストフレームワークです。 もともとはシェルスクリプト版Log4jとなるLog4shのテストのために開発されたものだそうで。 bashだけではなく、bsh、ksh、zshなどにも対応しています。 導入してみよう 導入は２通りあります： v2.1.6のリリースをダウンロード・展開して使用する。 gitリポジトリをクローンして使用する。 テストに使用する、ということもあり、v2.1.6のリリースを使用しようと思います。 ちなみにgitクローンを利用すると、執筆当時はv2.1.7preを導入できます。 インストール Githubよりリリースファイルをダウンロード(v2.1.6と表示されているやつ)します。【ダウン
ホワイトボックステストにおけるカバレッジ（C0/C1/C2/MCC）について - Qiita
本稿では以下のサンプルコードを用いて、ホワイトボックステストにおけるカバレッジ（C0/C1/C2/MCC）について説明します。 if(条件文a1 || 条件文a2){ // 判定条件A 命令文X; } if(条件文b1 || 条件文b2){ // 判定条件B 命令文Y; } else{ 命令文Z; } 命令網羅 (statement coverage) (C0) それぞれの命令文が少なくとも1回は実行される ようにテストを設計します。上記のサンプルコードの場合、カバレッジ率を100%にするためのテストケース数は2通りとなります。 テストケースNo. 条件文a1 条件文a2 条件文b1 条件文b2 判定条件A 判定条件B 命令文X 命令文Y 命令文Z
「カバレッジが高ければ、品質が高い」と誤解している危険な思想家の皆様へ - Qiita
皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか？少なくとも私は今までテストカバレッジ100%を追求していました。「C0/C1カバレッジ100%」がユニットテストの完了条件として含まれているプロジェクトも多いかと思います。 本稿では、「カバレッジが高ければ、ソースコードの品質が高い」という命題がなぜ誤っているのかを論理的に証明し、カバレッジを計測する本当の目的、そして推奨されるカバレッジの目標値について紹介したいと思います。 「カバレッジが高ければ、ソースコードの品質が高い」はなぜ間違っているのか？ カバレッジを計測する本当の目的 バグを潜在させてしまう恐怖のテストケース・アンチパターン カバレッジの目標値は100%にするべきではない カバレッジの目標値は何%にするべきなのか？ （テストカバレッジの種類については『ホワイトボックステストにおけるカバレ
ユニットテストを書こう！ - Qiita
ソフトウェアエンジニアにとって、ユニットテストは重要です。僕はなるべくユニットテストを書くようにしており、ソフトウェアエンジニアはもっとユニットテストを書くべきだ、と考えています。ここで言及している「ユニットテスト」は、単なる「テストコードによる自動化」全体を指すのではなく、「テストから見えてくるグーグルのソフトウェア開発」で登場した用語である「Sテスト」を指します。 「テストから見えてくるグーグルのソフトウェア開発」では、テストコードが対象とするプロダクションコード(製品コード)の規模、S、M、Lとサイズごとに分類しています。 「Sテスト」とは、テスト対象のクラスのみを対象にしたテストを行うことを目的としています。テスト対象以外のクラスの処理は、積極的にモックを多用することで、テスト対象のクラスの振る舞いを確認します。 Sテストは主に品質向上に寄与すると「テストから見えてくるグーグルのソ
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
