初心者がテストコードを書くようになった経緯とオススメのテストフレームワーク｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
初心者がテストコードを書くようになった経緯とオススメのテストフレームワーク 初めまして会社の隅っこで働いているvolと窓際で働いてるnagodonです。 今回は機会がありまして別のプロジェクトメンバー同士で技術ブログを書くことになりました。 テストコードを業務で使ったことがなかった二人が探りながらテストコードを書いたお話を、 前半をvol、後半をnagodonが行っていきたいと思います。 よろしくお願いします。 テストコードを書き始めた切っ掛け 私、volのプロジェクトでの切っ掛けは唐突でした。 ちょっと難しい機能を実装する事になり以下の内容で悩んでました。 1.時間足りない・・・ 2.仕様が複雑で設計大変 3.分担難しいけど一人じゃ間に合わない・・・ でもやらなくちゃいけないんだよ！！ 時間が無いながらも大きな機能から小さい機能を切り出して 一個一個丁寧に設計 設計が出来上がった所、 手
【単体テスト設計】どのようにしてテストコードを書くのか？
テストコードは重要なものです。対象のコードの品質を担保してくれるばかりでなく、自動テストによって改修時のバグ発生を未然に防いだり、リグレッションテストの手助けにもなるでしょう。 反面、テストコードの作成には、それなりの工数が掛かることも周知のとおりですから、工数をかけたくないプロジェクトでは後回しにされてしまいがちです。 テストコードとは メソッドなどの実行結果が適切かどうかをコード上で試験するものです。以下に例を挙げてみましょう。 例は２つの引数を合計する単純なコードです。 public int sum(int a, int b) { return a + b; } これに対してテストコードを書いてみます。jUnitのメソッドを使ってみましょう。 public void testSum() { int result = sum(1,2); assertEquals(result, 3);
単体テスト設計のコツ
Copyright © 2011 日本システム開発株式会社 All Rights Reserved 日本システム開発株式会社 ESEC2011 ブース内セッション 単体テスト設計のコツ http://www.nskint.co.jp 2 Copyright© 2011 NIHON SYSTEM KAIHATSU CO., LTD. 目次 1. ユニットテストについて知っておかないといけないこと 1-1. 品質問題の原因とユニットテストの関係 1-2. ソースコードレビューとユニットテストの違い 2. 有効なユニットテストデータの与え方[事例] 2-1. [事例1] 有効な値が10～20のunsigned short変数 2-2. [事例2] 参照のみ行う領域の確認 2-3. [事例3] メモリ破壊が起きるコピー処理 3. 危険コードに対するテストデータの与え方[事例] 3-1. [事例1]
ユニットテストの綺麗な書き方 - 超ウィザード級ハッカーのたのしみ
テストばっかり書いている。テストコードなんかの綺麗さを追求しても仕方ないかなと思っていたのだけれど、適当に書いていると重複が多くて大変で、シンプルに楽に書くコツみたいなのを掴んできたのでメモしておく。JUnitを対象にする。 テストクラスの単位 ユニットテストは機能要件をテストするものだ。非機能要件（性能、保守性、etc）などはテストできない。ユニットテストを書けるようなコードは保守性も上がるし、テストがあるコードは壊せないのでチューニングもしやすいというのは事実だろうが、これらをユニットテストで確認することはできない。 機能をテストするのだから、JUnitのクラスは機能（function)ごとに分けるのが自然だ。基本的にはクラス・メソッドごとになるかと思う。普通は機能ごとにクラスがあって、そのサブ機能がメソッドになっているものでしょう。したがって、クラスとそのテストのクラスは１対多にする
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
ユニットテスト改善ガイド | DevelopersIO
先日、日本Javaユーザグループ（JJUG）主催のJJUG CCC 2013 Fallで、「ユニットテスト改善ガイド」というタイトルで登壇してきました。自分の経験を元に、ユニットテストをチームや組織へ導入する時に起こりえる問題とその解決のヒントに関するセッションです。本エントリーではそのセッションの内容を再構成して公開します。 はじめに 近年のシステム開発では、ユニットテストや継続的インテグレーション（以下、CI）の導入は必要不可欠と考えられています。とはいえ、どんな組織（チーム）でも簡単に導入できているわけではありません。特に、大きな組織や古くからの慣習を残している組織では導入したくとも中々進まないと感じているところが多いのではないでしょうか？。 私は、これまでに多くの開発現場でユニットテストやCIの導入について推進してきました。成功したケースもあれば失敗したケースもあります。そして、失
ふつうのユニットテストのための７つのルール - ブログなんだよもん
最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記： テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記： もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定
これだけは覚えたい、ユニットテストを書くための４つのデザイン - Qiita
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
