GitHub - stackframe-projects/pgmock: In-memory Postgres for unit/E2E testsYou 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
テスト(コード)レビューの方針 書きなぐり版 - うさぎ組
牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか？もしあったら記事にはります。」 僕のコメント「書いていません！」 僕のコメント「書きました！」 僕の主張 本記事は僕の実験結果（経過報告）であり、
テスト駆動開発（TDD）はもう終わっているのか？ Part 2 | POSTD
前編はこちらです 4：テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が
TDDという名の幻想... - Qiita
TDDは死んだ。テスティングよ栄えよ。 by DHH http://d.hatena.ne.jp/yach/20140424#p1 【翻訳】TDD is Fun http://diskogs.hatenablog.com/entry/2014/04/25/085112 を読んで思ったことをつらつらと書いてみます。 TDDはできれば、やったほうが良いのは確か？です。 しかし、実際の開発現場で全面的に採用するのは ミドルウェア等の画面の存在しないソフトの開発以外では ほとんどの場合、無益です。 なぜなら、TDDを採用すると開発時間が膨らむ、すなわち、開発コストが 膨らむからです。そして、ソフト開発では細かな仕様は変化していきます、 するとTDDではそれに合わせ、テストを修正していかなくてはなりません。 また、TDDで書かれたテストが全てのケースを抜けなく網羅できていること は稀です、抜けは必ず
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
パラメータの正当性検査とユニットテストのカバレッジ | DevelopersIO
渡辺です。 最近はユニットテストの導入方法などに関するエントリーが多かったので、今回は実用的な小ネタとして、メソッドにおけるパラメータの正当性検査とユニットテストについて紹介したいと思います。 パラメータの正当性検査 はじめにパラメータの正当性検査について復習しましょう。Javaプログラマであれば読んでないことが許されないEffective Java（第2版P.175、ただし絶版）には次のように記述されています。 ほとんどのメソッドとコンストラクタは、パラメータとして渡される値に関して何らかの制約を持っています。たとえば、インデックス値が負であってはいけないとか、オブジェクト参照がnullであってはいけないというのが普通です。このような制約は明確に文書化すべきであり、メソッド本体の初めに検査することで制約を強制すべきです。これは、エラーが発生したらできるだけ速やかにエラーを検出するようにす
ユニットテスト改善ガイド | DevelopersIO
先日、日本Javaユーザグループ（JJUG）主催のJJUG CCC 2013 Fallで、「ユニットテスト改善ガイド」というタイトルで登壇してきました。自分の経験を元に、ユニットテストをチームや組織へ導入する時に起こりえる問題とその解決のヒントに関するセッションです。本エントリーではそのセッションの内容を再構成して公開します。 はじめに 近年のシステム開発では、ユニットテストや継続的インテグレーション（以下、CI）の導入は必要不可欠と考えられています。とはいえ、どんな組織（チーム）でも簡単に導入できているわけではありません。特に、大きな組織や古くからの慣習を残している組織では導入したくとも中々進まないと感じているところが多いのではないでしょうか？。 私は、これまでに多くの開発現場でユニットテストやCIの導入について推進してきました。成功したケースもあれば失敗したケースもあります。そして、失
VOYAGE GROUP エンジニアブログ : プライベートメソッドのテストは必要ない！！
2013年11月12日16:19 カテゴリprogramming プライベートメソッドのテストは必要ない！！ こんにちは、RPAの関口です。 最近週に一度、来年の新卒達と一緒にTDDをやりながらワイワイガヤガヤしております。そのなかで「プライベートメソッドのテストはどうすれば良いのか？」 という話題がありました。プライベートメソッドのテストについては プライベートメソッドのユニットテストは書かないもの？ がよくまとまっていると思います。プライベートメソッドのテスト方法について考える中で「TDDの手順に従えばプライベートメソッドのテストがしたくなることは無い」のではないか？と思うようになりました。 プライベートメソッドはリファクタリングの結果現れる！ 数値の配列を渡すと平均を計算して返してくれる機能を持ったクラス、AverageCalculatorを作りたいとします。平均計算の手順をまとめる
テストフレームワークのほうのUnityでC言語でもTDDを試す - Bye Bye Moore
奥さん、僕ぁC言語でもTDDしたいんですよ！ ……というわけで、Rubyで実現する素敵なC言語TDD環境、Unityです。 3Dゲームを作るアレではなく、TDD用テストフレームワークです。 UnityはRubyistにはお馴染みのRackを使っています。 Ruby&Rack環境が方は先に導入しておいて下さい。 導入が終わりましたら、 "公式様"にとんで頂き、 下の方にある「download unity」から圧縮ファイルを入手します。 これを解凍すると色々と並んでいます……が 今回用があるのはexampleです。 これの中身を詳しく見て行くと $ ls examples/ helper rakefile_helper.rb test makefile readme.txt test1.out rakefile.rb src test2.outとなっています。 テスト対象のファイルはsrc、
単体テストフレームワーク(xUnit)に関すること - 勘と経験と読経
このブログエントリの言いたいことがわかるようでわからなかったので、整理してみる記事。ドキュメントベースの単体テストとxUnitの類いの単体テストフレームワークの違いに関する私見。ツール(手段)の話ではなく、目的を中心に考えれば良いと思っている。 もし、ドキュメントベースの単体テストをそのまま踏襲したままで、xUnitを導入しようとするならば、もう一度テストの対象や目的を確認してください。xUnitは手段でしかありません。xUnitは小さなプログラムを動作確認するために作られたツールです。 ドキュメントベースの単体テストでxUnitを導入する前に考えて欲しいこと | DevelopersIO ドキュメントベースの単体テスト 例えばこんな「ドキュメントベースの単体テスト」が行われていて、いきなりxUnit類のツールを適用するとかなり混乱すると思われる。 割と「単体テスト」というものを実施するこ
ユニットテストが何のことかわからなかったわけだが。 - 馬車馬のクリップボード
2013-10-08 ユニットテストが何のことかわからなかったわけだが。 私事 いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめこちらの記事を読んだ。 まず最初に、ユニットテストってなんぞ？となり、はてなのキーワードを見たのち、一応グーグル先生にも訊いてみた。結果、単体テストのことらしいと把握。自分が認識してる単体テストと上記の記事で言われてるユニットテストが同じものであるかは置いといて、単体テストをやらないプロジェクトの恐ろしさに震えた。 自分は基本的にエンドさん相手に仕事してる。たまに違うときもあるけど、基本的にエンドさんに直接顔合わせる機会がある仕事が大半。んで、碌にテストしてないようなものを放り込むと最終的に残された人間が泣きを見る状況に陥らされる。 なので、単体テストもしないプロジェクトって経験したことないんだけど、ブコメとか見ると案外そういうプロジ
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
書いたコードが一発で動作するとなぜ不安なのか : akiyan.com
書いたコードが一発で動作するとなぜ不安なのか 2013-04-21 プログラミングにおいて少なくないコードを一気に書き上げたとき、そのコードが一発で動作 or テストケースに通るとなんともいえない不安を覚えるのは、プログラマーなら誰でもあるあるネタだと思う。「本当にこれ、一発で動作しちゃっていいの？ 俺、そこまでミスしないプログラマーだっけ？」なんて自分を疑ったりする。 このあいだもそんなことがあったんだけど、ふと気になった。不安になる理由は、自信のなさからくるものだけだろうか？ ちなみに、書いたコードが正しく動作しないとき、コードを修正すると不安になることはない。一体、なぜ？ 一発で動作したブラウザの画面を見ながら、考えてみて、閃いた。「コードの修正は、書いたコードを見直す機会にもなっているから」じゃないだろうか。コードの見直しは「リファクタリング」といっていもいい。 一発で動作してしま
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
Unit Test vs Functional TestそしてClean Code - masayang's diary
Agile2008でもらったゴムバンドを未だに手首につけている。確かBob Martinだったと思うが、テスト駆動開発と「Clean Code」の関係について熱く語っていた年だ。 メソッドは短く。 メソッドが実現することは一つ。 あるメソッドのテストに色々と条件を設定しているのなら、それはClean Codeではない。 だが我々はその基本を簡単に忘れてしまう。色々とテストのための道具が揃ってきたせいもあろう。基本を忘れて一つのメソッドに色々と詰め込みすぎるとテストが大変になる。Mockがあっても、だ。Fixture使うのはさらに大変だし、Seleniumとかで入力から何から条件を与えるのはもっと面倒。そしておそらく抜けが発生する。 最近、内職でPython使ったアプリを組んでいるのだが、今回は上記「基本」を徹底するようにしている。例えばこんなコードがある。 def nearby(reque
TDDを理解するためのまとめ - Logic Dice
わんくま同盟名古屋勉強会#9に置いて、biacさんのTDDに関する話が出たので、少し自分がTDDについて思うことを纏めてみました。 TDDが説明されるのを聞く度、見る度、多分説明している本人は分かっているのだろうけれど、それが他の人に本当に伝わっているのかが怪しいと思ったためです。 というのも、自分が（多分）理解するまでに、酷い回り道をしたもので。 また、biacさんのTDDに関するWebサイトはこちら。 TDD.NET - http://www.tdd-net.jp/ 以下、長文注意。 背景 まず、自分がTDD(より正確に記述するなら、「テストファースト*1」が正しく、TDDではない)をまともに実践しようと思って始めたのが、大学の4年時の最初なので、今から18ヶ月程度前です。 とある研究室のプロジェクトで使いたいという話になり、そこで実践を行いました。当時の環境はJDK + JUnitで
【コラム】攻略! ツール・ド・プログラミング (13) JavaScript用のユニットテストフレームワーク「JsTestDriver」」 | エンタープライズ | マイコミジャーナル
JsTestDriverとは JsTestDriverはオープンソースで開発されているJavaScript用のユニットテストフレームワークである。JavaScriptの場合、通常は実行エンジンがWebブラウザに依存するため、ブラウザごとに個別にテストしなければならないという難点がある。JsTestDriverを使うことでその悩みは解消できるだろう。 JsTestDriverはWebサーバとして動作するフレームワークである。テストコードはJavaScriptで記述して指定されたディレクトリに配置する。WebブラウザからJsTestDriverの特定のパスにアクセスすると、そのブラウザがテストを実行する環境として登録される。Webブラウザは複数同時に接続しておくことができる。 実際にテストを実施すると、接続されているすべてのWebブラウザのJavaScriptエンジンそれぞれでテストコードを実
YUI Testを使ったJavaScriptユニットテストのすすめ
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、検索事業部の角田です。 私が担当しているプロジェクトではPHPUnitとSeleniumを使ってテストを行っています。そして、最近YUI TestというJavaScriptによるユニットテストライブラリを使い始め、JavaScriptのユニットテストがとてもいい感じに思えてきたのでご紹介します。 YUI Testは、Yahoo! Developer Networkにて公開されているYahoo! UI Libraryの数多くあるコンポーネントの中の一つです。その名の通り、JavaScriptのユニットテストを行うライブラリです。JavaによるJUnitやPHPによるPHPUnitを使ったことのある方であれば、すぐに使い方
やる気が持続するテストの書き方 - Tlab Blog
こんにちは。nayです。TDDと出会ったのは6年以上前ですが、最近、やっと"友達"になることができました。 テストを楽しく積極的に書く心境になれるかどうかは、気だてや価値観や根性の問題ではなく、テクニックの問題であると思います。そこで、テスト嫌いの私がどうやってTDDと友達になれたかを、３つのポイントに絞ってご紹介したいと思います。 1. 関心事だけをテストする 2. DRYにする 3. RSpec 私がテストが嫌いになった理由の一つは、コード変更時にテストが足かせになることです。出るべくして出たエラーはありがたいのですが、関係ない部分で大量にエラーが出ると直すが大変で嫌になってしまいます。また、直そうとしたときに、テストのコードが読みにくいと、難行苦行に直面することになります。最初の２つのポイントは、このようなテストの「丈夫さ」と「読みやすさ」に関わるコツです。 関心事だけをテストする
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - atesgoral/jsunity: Lightweight Universal JavaScript Unit Testing Framework