テスト講義 - test-class.mdYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
ブラックボックステストとホワイトボックステスト | DevelopersIO
テスト分類のひとつにブラックボックステストとホワイトボックステストがあります。 ブラックボックステストとは、テスト対象の内部を意識せずに外部仕様のみからテストケースを構築していく手法です。ユニットテストであれば、テスト対象となるメソッドの実装（コード）を意識せず、メソッドのAPI仕様からテストケースを作成することになります。 一方、ホワイトボックステストでは、テスト対象の内部を意識し、どのような構造であるかを踏まえたテストケースを構築します。ユニットテストであれば、テスト対象となるメソッドの実装（コード）を意識し、分岐や繰り返しなどを考慮しつつテストケースを作成することになります。 さて、ユニットテストはブラックテストでしょうか？ それともブラックボックステストでしょうか？ 「JUnit実践入門」では次のように記述しました。 本書で扱うユニットテストは、テスト対象の内部ロジックを考慮して行
xUTP Chapter26. Dependency Injection
Java SE 9を、新たに導入されたモジュール・システム（Jigsaw）を中心として紹介します。JJUG CCC 2017 Fallの発表資料です。 補足: p. 7 正しくは「JMX」→「JMS (Java Message Service)」。JMXはJava SE内の、モニタリング用の仕組みです。 p. 43 これに加えて、SPIの実装を提供するモジュールも、モジュールレイヤーに含まれます。具体的にはConfiguration.resolveAndBindの動きです。 p. 47「Oracle JDKでは、外部モジュールの非公開メンバへのリフレクションが可能」は、OpenJDKでも同じ動作です。「HotSpot系の」とすべきところでした。 このスライドはCC Attribution Licenseの元に、利用・改変・再配布をライセンスします。
プログラマーが「テストを書く」といい、テストエンジニアが「テストをする」という理由について - うさぎ組
以前にGistに書いていたのですが、忘れそうなのでリンク貼りつつ、転載しておきます。 【プログラマーが「テストを書く」といい、テストエンジニアが「テストをする」という理由について.md】 はじめに ここに書かれているのは、「主目的」であって、プログラマーもしくはテストエンジニアが「他のことを考慮していない」という意味ではありません。あと、僕の解釈なので一般論というわけではないないです。 プログラマー：「テストを書く」 プログラマーは基本的に「テストを書く」というと思います。実際に書いているんですけど。これ、手動テストしかなかった時代は、どうやって言っていたのかわかりませんけど、これは非常に的を得ていると思うのです。プログラマーの主眼は「要求を設計し実装すること」にあります。そしてその意志はプロダクトコードとなって表現されます。そう、プロダクトコードというのは、表現手段なんです。なので、彼ら
Ruby スクリプトのユニットテスト・チュートリアル - WebOS Goodies
WebOS Goodies へようこそ！ WebOS はインターネットの未来形。あらゆる Web サイトが繋がり、共有し、協力して創り上げる、ひとつの巨大な情報システムです。そこでは、あらゆる情報がネットワーク上に蓄積され、我々はいつでも、どこからでも、多彩なデバイスを使ってそれらにアクセスできます。 WebOS Goodies は、さまざまな情報提供やツール開発を通して、そんな世界の実現に少しでも貢献するべく活動していきます。 少し前に公開した Ruby 用 JSON クラスに数多くのバグを仕込んでしまい（たいへんご迷惑をおかけしました m(_ _)m）、テストの重要性を改めて痛感している今日この頃です。今後も開発を続けるにあたって、現在の行き当たりばったりなテスト方法ではとてもやっていけないと危機感を持ちまして、きちんとしたユニットテストの方法を調べてみました。 で、実際に試してみたと
リッチなテスティングフレームワークとテストの可読性の問題 - tomykaira makes love with codes
この記事は DRY原則とテストの可読性 - ✘╹◡╹✘ への応答という側面があります。テスト駆動 Javascript を読みおわりましたが、そこにもおなじようなことが書いてあったので、その考察でもあります。 テスト駆動JavaScript作者: Christian Johansen,長尾高弘出版社/メーカー: アスキー・メディアワークス発売日: 2011/11/25メディア: 大型本購入: 13人 クリック: 287回この商品を含むブログを見る TL;DR DRY ではなく sustainability を目標にする テストコードが技術的要素に踏み込みすぎないようにする テストの可読性は能力の低いフレームワークで書けば高くなるものではない。テスト対象、環境の性質につよく依存する DRY 厨というのはコードを省みないよりもタチが悪い。彼には DRY という錦の御旗があり、「やりすぎだよ」
DRY原則とテストの可読性 - ✘╹◡╹✘
DRY原則に従おうとするほど、テストコードがどんどん読みづらくなる。 The RSpec Bookに答えがあるかと思って読んでみたものの、「あるある」と一言述べているだけだった。辛い。 テストコードが読みづらくなる例を示すために、1つRubyのライブラリをつくった。 値とパターンを与えてValidationを行う機能を提供するライブラリ。 実装60行、テスト120行なので、詳しく見たければすぐ読めると思う。 最近不本意ながらキラキラネームの命名力が上がってきたと思う。 avalon - A validator implementation for Ruby https://github.com/r7kamura/avalon 冗長だが読みやすい例 letもsubjectもローカル変数も何も用いずに率直に書いたテストコード例がこちら。 冗長だが読みやすく、テストコードを見ればライブラリの使い
[lib] モックとスタブの違い
TEST http://d.hatena.ne.jp/devbankh/201001 モックやスタブを使った効率的なユニットテスト http://d.hatena.ne.jp/devbankh/201002 モックとスタブの違い コミュニケーション http://d.hatena.ne.jp/devbankh/20051124 簡単かつ効果的に話すために "モックオブジェクト"という言葉は、テストのために本物のオブジェクトをまねる特殊なオブジェクトを表す言葉として定着した。しかしモックという言葉は元々スタブをキャッチーにしたものでなく、[スタブを使ったのとは別の] ユニットテスト方法を用いるためのものなのだ。この記事では、モックオブジェクトのファンに好まれる相互作用中心のテストと、よく行わている状態中心のテストスタイルとの違いを説明するために、モックとスタブの違いについて掘り下げる。 目次
![[lib] モックとスタブの違い](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
テストについて考える
テストについて考える 1. テストにつ いて考える 2010/11/30 Ryutaro “Ryuzee” YOSHIBA http://www.flickr.com/photos/nicolas-hoizey/2693162677/ 2. 自己紹介 Ryuzee @ryuzee http://www.ryuzee.com/ http://www.flickr.com/photos/adforce1/2539903964/ 3. アジャイルコーチ 認定スクラムマスター オープンソース開発者、翻訳者 Shibuya.tracのスタッフ TIS,野村総合研究所を経てベンチャーのCTO http://www.flickr.com/photos/royskeane/413103429/ 4. 今日の話のコンテキスト • ゕジャルな立場から話をします • がウォーターフォールでも適用可能 です.(
今日からはじめるJS UnitTest
なぜ「テストを書く理由」が重要なのか テストもプログラムの一部 ただし、直接は機能を追加しない しかも、メンテナンスコストは高い
JUnit 強化キャンプに参加してきた #junitbc - Diary of absj31
JUnit 強化キャンプ : ATND 2012/04/07 JUnit 強化キャンプ #junitbc - Togetter (写真：会場となった某漫画喫茶個室内に映し出される実践映像を眺める参加者一同) 私自身、勉強会に於いてテスト関連のイベントには参加しつつも(TDDBC等)、そこから先テストに於いて諸々を(Bootからの次の段階である)ブースト(Boost)出来ていなかったので、このイベントを見つけ次第『これは！』と思い参加してきました。 会場はまんがねっとラウム新宿本店。 自身としては、漫画喫茶で勉強会やるってのは初めてだったので、『(諸々)どうなんだろう？』という気持ちがありましたが、実際やってみると殊の外快適で"これは良い"という感じでしたね。ネット回線(立地上の問題で時々調子が悪い時があった)や部屋に対する定員を上手く調整すれば、利用場所としてはかな〜り良いものになるのでは
RSpecによるユニットテストの書き方 — recompile.net
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
GHUnitで単体テストをしてみよう - mixi engineer blog
初めまして。プログラマのショウといいます。 現在、mixiの公式iPhoneアプリを担当しています。 今回は、iPhoneアプリ開発におけるGHUnitを用いた単体テストについて紹介したいと思います。 ★ テストとは 本題に入る前に少しだけ、テストという概念について整理してみましょう。 ソフトウェアを開発する上での「テスト」という言葉は、「コンピュータのプログラムを実行し、正しく動作するかを確認する作業のこと」を指します。 そしてこの「正しく動作するかを確認する方法」として主に以下の2通りがあります。 ・ ホワイトボックステスト ・ ブラックボックステスト ホワイトボックステストとは、「命令網羅」「分岐網羅」「条件網羅」などの方式を用いて、プログラム内部の動作がプログラマの意図通りとなっているかを確認するものとなります。 これに対してブラックボックステストとは、プログラム内部に関係なく、外
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
テストが間違ってたら？ - 日々常々
「テストが間違ってたらどうするんだ」 自動テストの話をするとよく言われます。テストが間違ってたらわからないじゃないか。手動テストであれば、注意深く目で確認していれば間違いに気づけると言う主張です。 「目で確認していれば気づける」のは間違いではありません。必ず気付けるわけではありませんが、十分な知識を持った人が、十分な集中力と責任感をもってエビデンスを確認すれば、誤りに気付ける可能性は高いと思います。 品質(主に機能性)を目的とした自動テストでも、それを行う必要があります。それがテストコードのレビューです。 手動テストの場合、テスト実施前に手順や確認項目のレビュー、実施中の確認、実施後のエビデンス確認と、人が確認するタイミング*1が三カ所あります。 これに対し自動テストの場合、テストが書かれた時のみ。実行中は勿論、実行結果の確認に注意はありません。ただ成功か失敗かだけなので。ならば、テストコ
BDDについて自分なりにまとめてみた - ukstudio
BDDという言葉も割と人によって指すものが違うようなので「俺の中でのBDDはこうだよ」って内容のエントリ。別に絶対的なものでもないと思うので参考までに 結論から とりあえず結論だけ知りたい人向けに。 BDDにはふたつの種類がある TDDの言い換えのBDD(開発寄り) ATDD(受け入れテスト)でのBDD(ユーザ寄り) 振る舞い BDDは振る舞い駆動開発と言われたりするように、テストという言葉のかわりに振る舞いという言葉を使う。日本語的には仕様と言うほうがわかりやすいかもしれない。多分、BDDのイメージが掴みにくいのはこの振る舞いという言葉にあると思う。と言うのも振る舞いと言うのは、人の立場よって変わるからだ。例えば、プログラマがあるクラスを実装している時に言う振る舞いはそのクラスのメソッドとかの仕様になる。逆にユーザレベルの人が言う振る舞いはアプリケーションの要件・動作を言うだろう。 つま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
私にとってのテスト
#NagoyaTesting アジャイルなテストの見積りと計画づくり
テストコードのリファクタリング
データベースを使った自動テストについて