xUTP Magazine - ぺけま
xUTP Magazine について 『xUTP Magazine』、略して『ぺけま』は、xUTP読書会の有志による xUnitester の xUnitester による、xUnitester とそうでない人のためのウェブ雑誌です。 最新号 0004号 巻頭言 xUTP Topics: 第三回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」 TDD Live 番外編(TDD序破Q) 編集後記 バックナンバー 0003号 xUnitester Hotlinks: 第一回 和田卓人さん(下) goos 読書会への誘い 来年(2012年)のTDDBC予報 0002号 xUnitester Hotlinks: 第一回 和田卓人さん(上) xUTP Topics: 第二回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」 mockitoでサ
プライベートメソッドのテストは書かないもの？ - t-wadaのブログ
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
テスト駆動開発って何だろう | DevelopersIO
はじめに モバイルアプリサービス部の中安です。 このたび、テスト駆動開発(Test Driven Development = TDD)の社内読書会を数ヶ月に渡って参加させていただきました。 原題: Test-Driven Development By Example 著: ケント・ベック 訳: 和田卓人 こういうものに参加するのも初めてなので「なんとかついていく」という感じでしたが、 最終的には無知識だった初めの印象から変わった部分も多く、有意義だったなぁという感想に至りました。 すでに社内読書会については素晴らしいまとめがありますので、 詳しくご覧になりたい方は下記のリンクをご覧くださいませ。 『テスト駆動開発』読書勉強会 では、自分はここに何を書いていくかというと、 「テスト駆動開発って何だろう」から始まった自分が読書会を通じてわかったこと 弊社に直接お越しいただき話をしていただいた、
xUTP Magazine - xUTP Topics: 第三回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」
書いた人：@yujiorama(id:yujiorama) 目次 目的 はじめに テストの匂い テストコードの匂い Obscure Test Conditional Test Logic Hard-to-Test Code Test Code Duplication Test Logic in Production 振る舞いの匂い Assertion Roulette Erratic Test Fragile Test Frequent Debugging Manual Intervention Slow Tests プロジェクトの匂い Buggy Tests Developers Not Writing Tests High Test Maintenance Cost Production Bugs さいごに 目的 この連載記事の目的は次のような感じです。 xUTP読書会で得られた知見を
週刊ソフトウェアテスト 2014-48 #swtest_jp - うさぎ組
前書き ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。 ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！ kyon_mmの意見 POSTDさんが【翻訳】「ほとんどのユニットテストが役に立たない理由」を読んで | POSTDを公開してくださいましたが、翻訳対象の記事を書いた人はJames O Coplienの「ほとんどのユニットテストが無駄になる理由」を勘違いしているということ、元記事自体また、元記事でのJames O Coplienからのコメントでも明らかです。この記事を読んでたくさんの人がCoplienの意見を誤解してしまったの
「いまさら聞けないTDD/BDD超入門」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords
いまさら聞けないTDD/BDD超入門（4）： 開発現場で保守性の高いTDD／BDDを実現するための3つのポイント――テストレベル／網羅性とは 開発現場でTDD／BDDを導入するためのポイントを大きく三つに分けて解説。テストレベルや網羅性、サイクルタイムについても紹介します。（2014/10/17） いまさら聞けないTDD/BDD超入門（3）： TDD/BDDにおける「振る舞い」の意味するところとは何なのか BDD初心者が持ちがちな3大疑問点を提示して、さまざまな角度からそれを明らかにしつつ、振る舞いを表現する2つのテクニックを紹介する。（2014/4/30） いまさら聞けないTDD/BDD超入門（2）： TDD／BDDの思想とテスティングフレームワークの関係を整理しよう TDD／BDDの思想に触れ、フレームワークとしてxUnit、JBehave、xSpec、Cucumber、Turnip、
開発現場で保守性の高いTDD／BDDを実現するための3つのポイント――テストレベル／網羅性とは
開発現場で保守性の高いTDD／BDDを実現するための3つのポイント――テストレベル／網羅性とは：いまさら聞けないTDD/BDD超入門（4）（1/3 ページ） 連載目次 前回の『TDD／BDDにおける「振る舞い』の意味するところとは何なのか」までで述べたような、TDD／BDDを導入するときには、現場で「で、今までやってきた単体テストと結合テストって、どうやってこれに組み込めばいいんだっけ？」「網羅的なテストをどうやって書けばいいんだろうか？」「テストを先に書くだけくらいにしか違いがないのではないだろうか？」などの疑問が出てきます。 今回は、これらの導入時の疑問を解決するようなパターンを紹介します。まずは説明のためにいくつかの言葉の定義を紹介してから、どういったことで保守性の高いTDD／BDDを実現できるかを紹介します。 テストレベルの定義 大まかに言えば、「テストレベル」とはテスト対象の大き
恐怖のFragile Tests問題
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料）NTT DATA Technology & Innovation10.1K views•63 slides
Uncle Bobのリトル・モッカー | POSTD
interface Authorizer { public Boolean authorize(String username, String password); } public class DummyAuthorizer implements Authorizer { public Boolean authorize(String username, String password) { return null; } } こっちは「ダミー」です。 ダミーはどういった場合に使うのですか？ 実際に使用されるかどうかに関係なく、プログラムを進める時です。 例えば？ テストですね。実際に使われることはありませんが、何かしらの引数を渡す必要があります。 例を見せていただけますか？ はい。 public class System { public System(Authorizer author
Appleの新言語「Swift」を使ったテスト駆動開発と、機能の紹介｜CyberZ 公式エンジニアブログ
CyberZ 公式エンジニアブログ アドテクや最新のテクノロジーについて情報発信していきます ブログトップ 記事一覧 画像一覧 怠惰のすゝめ。Do･･･ » Appleの新言語「Swift」を使ったテスト駆動開発と、機能の紹介 2014-06-05 14:20:52NEW ! テーマ：ブログ 新言語「Swift」とは新プログラミング「Swift」は、先日のWWDCで突如として発表された、Appleの作った新プログラミング言語です。Objective-Cに比べてモダンな文法が盛り込まれていたり(どことなくScalaやC#に似ていたり)、速度が早くなっている特徴があります。 Xcodeとの親和性の高い連携も示唆されており、今後広まっていく可能性が十分にあると思います。FizzBuzzとはFizzBuzzとは、プログラミングの課題などでよく出される問題で、1から順番に数字のループを行い、3の倍数
テストコードを書く文化を根付かせたい─和田卓人｜【Tech総研】
日本におけるテスト駆動開発（TDD）のスペシャリストとして知られる和田卓人氏。講演活動やハンズオンイベントを通してテストの重要性を語り続けている。その深奥にあるプログラムの哲学とは── 父親がデータベース設計を得意にするソフトウェア・エンジニアで、受託開発の会社を経営していました。私は大学在学中からその仕事を手伝っていて、その延長で大学を出るとその会社の一員になりました。 そのころのことで一番印象に残っているのは、電子政府関連の公共システム開発に関わる大規模プロジェクトへの参加です。複数のSIerやソフトハウスが関わり、要件定義に時間をかけ、膨大な設計文書をつくっては、何千人というエンジニアを投入する、典型的な大規模システム開発です。私はそこにSEの一員として参加することになりました。 ただ、私は初日から生意気にも「Excelで設計書を書き続けるために来たのではありません」と嘆願して、基盤
テスト駆動検索のススメ (@tady_jp) // Speaker Deck
2014-02-07に開催された第３回ElasticSearch勉強会での発表スライド。 内容を一部修正しました。 株式会社じげん 多田雅斗@tady_jp
テスト駆動開発へようこそ
Node.js Native ESM への道 〜最終章: Babel / TypeScript Modules との闘い〜
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
テストのめどい話
最初にめどい言い訳をせねばならぬ俺は江島氏ともきょん氏とも面識はないですが、お二人ともが俺のことを知ってることを俺も知ってる程度には狭い業界であり。どちらかに肩入れしたいわけではないです。喧嘩したいわけでもないです。普段あまりここでは言及しないですが俺は今の仕事としてはテストを書いたりテストを実施したりする係をしてノリクチをしのいでおり、いわばテストは本業ですので、テストに言及することは今現在の同僚に対して意図しない受け取られ方をする可能性があるので困るので、それもあって普段はここではあまりテストの話はしないわけだが、だからと言って沈黙を破ってテストの話をするのが同僚に対して含みがあるというわけでもないです。とはいえ俺は大学等で真面目にソフトウエア工学の講義を受講したことがなく、経験と勘と昔取った杵柄だけで食ってるので、そういう意味では若干の後ろめたい気持ちもある。で、テストって何なん俺が
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
jstest
The cross-platform JavaScript test framework jstest is a testing framework for JavaScript that’s designed to run on any platform with minimal effort. It provides a familiar RSpec-style API for organising tests that can run on the following platforms: Web browsers: Chrome, Firefox, Internet Explorer, Opera, Safari Headless browsers: PhantomJS, SlimerJS Server-side platforms: Node.js, Narwhal, Ringo
[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)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
adultoruby
自動テストの誤解とアンチパターン in 楽天 Tech Talk
