現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
Re: モッククラス、下から見るか？横から見るか？ - うさぎ組
先日Twitterでリプライがきたのでみてみたら素晴らしいブログ( モッククラス、下から見るか？横から見るか？ )がありました。 プログラムにおける自動単体テストでモックをつかうべきかどうか悩んでいるというもの。 私なりにこれに回答しようとおもいます。みんなもなにかおもうところがあれば、SNSではなくブログにしてほしい。(Webからそのままアクセスできるという点において) 1. 基本方針 2. 仕様化テスト、レガシーコード改善、リファクタリングでつかう 3. トランザクションのcloseなどの後処理を確実に検知する。Rxや一部の書き方によってtry-with-resourcesがつかえなくても。 1. 基本方針 可能なかぎりモックライブラリはつかわず、コンストラクタDI(Dependency Injection)で解決できるならそうする 往々にして厳密な単体テスト(1ファイルにとじたテスト
ユニットテストの定義と価値とリスク - Qiita
特にインテグレーションテストとユニットテストの境界が秀逸であり，「インテグレーションテストは，私たちが変更できないコードに対して，書いたコードが機能するか？」ということが明言されています．実例として想像しやすいのが，データを保存する機能を持つクラスだと思います．いわゆるRepository Patternを用いたクラスであったり，ActiveRecordのようなDBと密結合しているようなクラスにあたります．このようなクラスはユニットテストはできず，インテグレーションテストを行うほうがベターです．逆にユニットテストは「私たちが変更できるコードに対して，書いたコードが機能するか？」をテストすることになります． 角の立つ言い方かもしれませんが， 関数の引数にフレームワーク固有の型を使った時点で一切ユニットテストができないと思ったほうが良いです．また，そのようなフレームワーク固有の型を使った関数を
僕たちがテスト駆動開発をする理由 - Qiita
追記(2019/11/2) 今回の記事で深く扱えなかったリファクタリングに関する記事を書きました。 「汚いコード、綺麗なコードって何？」リファクタリングを考えてみる テスト駆動開発とは テスト駆動開発とは、「テスト => 実装 => リファクタリング」という流れを何回も何回も繰り返してプロダクトを成長させていく開発手法です。 もう少し詳しく説明します。次の３段階を繰り返します。 1. テストケースを考えるフェーズ これは設計を考えることに等しいフェーズです。このオブジェクトがどんな機能を持っていて欲しいか、どういう風に使われるか、そしてその時にどんな結果を返して欲しいか、という思いをテストケースに込めます。 重要なのはこの時に実装のことは一切考えず、どう使われるかを考えることです。 2. 実装するフェーズ テストをパスするためだけの最低限度の実装をします。この時も抽象化やキレイなコードなど
テストを書くかどうか議論するの不毛だから、どうやってテストを書きやすくするか議論しよう - Qiita
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするかという記事がバズりました。みんなテストについて思うところがあるようだ。テストを書くべきか否かは机上の空論になりがちで不毛なので、どうやってテストを書くか、テストの書き方、について、種を巻いた私が書いておく。 もっと詳しい方からのお話お待ちしています。 書くこと テストの書きやすくするためのいろいろ（箇条書き） 書かないこと テストの基本 テストファースト 実装ありきでテストを書くのではなく、テストありきで実装を変える。 はっきり言って、テストを考慮せずに実装されたコードは、書き直さずにはテストできない。 そういう点で、テストなしで実装する選択肢は不可逆なので、初期実装では特に注意が必要。 クリーンアーキテクチャ(DDD) クリーンアーキテクチャの考え方はテストファーストを語る上で重要。私個人としてはまだクリーンアーキテクチャ
仕様変更に弱いからテストは書かない……？(´・ω・`)＜仕様変更を想定するならテストを書いてくれ頼む - Qiita
テスト書けない人をディスったらバズりました。 「スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか」 気になる反応があったので別記事にまとめておきます。 「仕様変更に弱いからテストは書かない」 テストがあると頻繁な変更に弱い、と考える方が複数いらっしゃるようです。実際に、スタートアップの現場では、昨日の決定が今日と違うなんてことはザラにあります。 私の立場は「仕様変更が多いならテストを書いてくれ頼む」です。絶対に間違いなく一行の変更も加えず書いたコードを捨てることが決まっているのなら、テストは不要な可能性が高いです。しかし私の経験上は、プロトタイプであっても変更を加えたくなることは多々あります。その際にテストがないと困るだろう？というのが今回の主張です。 前提 フロント、特にGUIは私が無知なので対象としません。 間違いなく書き捨てるコードは対象としません。少なくとも一週間
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか - Qiita
あまりにバズってしまったので、前書きを追加 ここまでバズってしまって正直すまんかった。 この記事はもともと愚痴記事をマイルドにして投稿しただけなので「テストを勧める」とか「テストを信奉する」とかそこまで強い意図は特にありません。（私がテスト好きなのは否定しません） 「テスト書こう」に対して「そんなコストはない」と言いながら、いろいろ問題が生じる現状を愚痴りたかっただけです。愚痴るだけだと生産性がないから、なんでこんなに認識が違うんだろうと原因を考えた結果、テストを書くことに対する技術で実際にコストが大きく異なるなと気づいて書いた次第です。 この記事の対象は「テストを書く技術がなく、テストを書く気がない」組織に所属する人です。 アジャイル開発において「テストコードは当然」なのか？という記事で（私の記事をきっかけとして）テストコードの「徹底」とか「カバレッジ100%」とかを批判し、トレードオフ
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
無法地帯にテストケースを追加する時にいつもやっている戦略 - laiso
数年開発続いてるけどテスト全くないみたいなよくあるコードベースを想定。 不具合を修正する時についでにリファクタリングしてドメイン層のテストを書く。 手動テストで不具合を再現 ViewからロジックをControllerへ移動し、Viewからは値の参照のみにする 移動したロジックをController内でプライベートメソッドに切り出す。返り値を(2)の値にセットする プライベートメソッドを外に出して関数→モジュール化する (4)のメソッドに対してテストを書き、失敗するのを確認する ポイントとしては 運用的観点ではなるべく早く不具合を修正してデプロイしたいので、リファクタリングだけ別のブランチでゆっくりやる 依存がでか過ぎで解決できなさそうなど問題があれば、その時点ではテストを書くのを諦める。行動したことで学んだIssueを起票する 具体的なリファクタリング方法は レガシーコード改善ガイド (O
「あるエンジニアがプログラムを紡いでいく様を見てみる」ライブコーディング・リプレイ - 日々常々
あるエンジニアがプログラムを紡いでいく様を見てみるでしたライブコーディングで言ったことや言わなかったことを書いてみます。 意識してるのは「コードをどまんなかに」です。 speakerdeck.com ……あ、このスライドのブログ書き忘れてた。 スライド中の「えらぶ」はだいたいIDEの機能を指します。なのでライブコーディング中に使用したIDEの機能も挙げようと思います。基本的にデフォルトのつもりだけど、vimとの兼ね合いで変更してるのもあるので、そこはごめんなさい。あとMacです。今回はメソッド抽出とかクラス間移動とかダイナミックなのがなくて地味だけど、便利な子たちなので使ってあげてください。 リプレイ 今日の公開コーディングはスゴい新鮮だった🎵 コミット後のソースには、どこに悩んだのか、どこにこだわったのかは残らないのですね。 実際のコーディングを見させて頂く事で、気づかされる事が多かっ
Android Test Night #1よかった - みんからきりまで
Android Test Night #1に参加してきた。 testnight.connpass.com 当日になっても補欠から繰り上がりそうになかったので諦めていたんだけど、ブログ枠が空いていると聞いて滑り込んだ。 何書けばいいか分からなくて困ったらどうしようと不安だったけど、全然そんなことはなくてたいへん面白い話がたくさん聞けてよかった。 発表内容 「コードレビューをより良くする Danger x Android」：とし氏 コードレビューをより良くする Danger x Android from Toshiyuki Hirata www.slideshare.net DangerというPRチェックツールの紹介とDeNAでの活用例の話。 PRを解析して自動で内容をチェックしたりプラグインを使って他のツールと連携したり色々出来るらしい。 便利そうだし導入ハードルも低そうなので弊社でもさ
Android Test Night #1 - Qiita
Android Test Night #1 - connpass コードレビューをより良くする Danger x Android Dangerはプルリクエストのメタ情報に対するLINTのようなものだと認識してます メモ GitHubコメントに「Review」と付くとチェックが走るようにしているらしい PRで"review"とコメントするとDangerが走る。大丈夫だったらチームにレビュー依頼のメンションが飛ぶ。駄目だと何が駄目だったのかをDangerがコメントに書いてくれる。 #android_test_night — 菊池紘 (@kikuchy) September 21, 2017 リポジトリにスクリーンショットを入れておいて、プルリクエスト時にアップデートすることでGitHubの画像Diffの恩恵に与られて便利 Danger Plugin機構があるらしい Dangerプラグインを
レガシーコードの触り方 / Working Effectively with Legacy Code
オープンセミナー2017@岡山
テスト計画の立て方 - Qiita
テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ
和田(t_wada)さんに技術相談をしました - CureApp開発者ブログ
2016 - 11 - 07 和田(t_wada)さんに技術相談をしました 二週間ほど前にはなりますが、 日本のTDD( テスト駆動開発 )の先駆者である和田さん(t_wada)をお招きして、 技術相談会を行いました。 日頃、開発時に感じていた悩みを聞いていただき、 和田さんにビシバシと解決していただきました。 そこで今回は特に印象に残った、 不安定なテストとの付き合い方 フレームワーク 選定基準 品質保証のやり方 について書こうと思います。 不安定なテストとの付き合い方 私たちは、普段から不安定なテストに悩まされていました。 不安定なテストとは、 ローカルでは通るけどCIでは落ちる 遅くて タイムアウト になるときがある など、コードでなく環境によって結果が左右されるテストのことです。 この不安定なテストによって、開発に新しく関わった人に毎回同じような説明をしたり、説明をし忘れて不要な対
クックパッド サマーインターンシップ2016の資料を公開します - クックパッド開発者ブログ
技術部開発基盤グループの @moro です。 クックパッドでは、昨年に引き続き今年も、夏の技術職インターンシップを実施しました。 クックパッドのインターンシップは前後半に分けた構成になっていました。まず前半はWebサービス開発に必要な技術の中から6つの分野に関する講義や実習を行いました。さらに後半は、前半の座学に合格した方を対象に、メンターとなる社員と一緒に実際の開発現場に入り、具体的な問題解決に取り組んでもらいました。 その中で、前半の講義に使った資料を公開します。 1日目 Git (@moro) 昨年に引き続き、講義初日はGit, TDD, Railsを1営業日で一巡りするという、忙しい構成でした。 Git編では、すでにGitを使っているエンジニアも多いだろうと想定して各コマンドの紹介などは最小限に済ませました。代わりに、Gitの内部構造を説明し「コミットを覚えておけばなんとかなる」感
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
組織にテストを書く文化を根付かせる戦略と戦術（2019夏版） / Strategy and Tactics of Building Automated Testing Culture into Organization 2019 Summer Edition
テスト駆動開発から品質保証へと橋を架ける / JaSST'18 Kansai from TDD to QA
組織にテストを書く文化を根付かせる戦略と戦術 / Strategy and Tactics of Building Automated Testing Culture into Organization
Clean Architecture & TDD
