2014/12/09 に DeNA 社内勉強会にお招きいただいて話した内容です
テストを書くか書かないかの状況判断 / Deciding whether to write tests - DeNA Tech Talk
2014/12/09 に DeNA 社内勉強会にお招きいただいて話した内容です
テストコードを書き始める前に考えるべきテストの話（2021年版） #scrumosaka / scrum_fest_osaka_2021
以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P…
HaskellでのTDDを楽しくするライブラリ methodを作りました。
はじめに Haskellでテスト駆動開発を行う際、純粋な関数は単体テストを書きやすいですが、 返り値がモナドの関数（この記事ではそのような関数をメソッドと呼びます）にたいして単体テストを書くのは簡単ではありません。 今回、メソッドに対して単体テストを書きやすくなるライブラリ methodを作成しました。 methodとは methodでは a1 -> ... -> an -> m b型の関数のことをメソッドと呼びます。 ここでmはモナドです。(->) rモナドを除く大抵のモナドはサポートしていますが、独自のモナドをメソッドにするにはMethod型クラスを実装する必要があります。 モックの作成 methodでは任意のメソッドのモックをDSLで書くことができます。 import Test.Method import RIO (throwString) f,f' :: Int -> String
組織にテストを書く文化を根付かせる戦略と戦術（2020秋版） / Strategy and Tactics of Building Automated Testing Culture into Organization 2020 Autumn Edition
ソフトウェアテストシンポジウム 2020 新潟 JaSST'20 Niigata 基調講演 2020年9月28日（月） http://www.jasst.jp/symposium/jasst20niigata.html
「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト
TDDを諦めることと、RSpecをやめること - 高柴ラボ
2014-10-17 TDDを諦めることと、RSpecをやめること Ruby on Rails Ruby RSpec 開発手法 最近Web上でも仕事場でも、RSpecをやめて別のテストフレームワークに変えようと思っている……みたいな話をちょくちょく見聞きするようになった。僕がRuby on Railsで開発を始めた2012年8月当時、すでにRSpecはテストフレームワークのデファクトと言ってよかった。一斉を風靡したRSpecが、なぜ今見直され始めているのか。 きっかけになったのは今年4月の、Rails作者であるDavid Heinemeier Hansson(以下DHH)によるTDD is dead発言だと思う。 5月にはこの発言によるTDDへの風評被害を重く見たKent Beck*1が、レフリーにMartin Fowler*2を迎え、DHHと相対するドリームマッチが開催された。この会談の
テスト駆動開発（TDD）はもう終わっているのか？ Part 1 | POSTD
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
Rubyにはウンザリ！動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD
この記事を書き上げるには、相当長い時間がかかりました。本来は今年の年明け、 Rubyの死 やデイヴィッド・ハイネマイヤー・ハンソンの TDDは死んだ がアップされて騒ぎになる前に投稿するつもりだったのです。昨年末に書いたツイートを見てください。 > Rubyにはもう飽き飽きした。理由はいろいろあるが、特にその副作用と、ステータスが可変なせいで大量のユニットテストを書かされるのにはウンザリだ。 @abevoelker Rubyの開発に関しては、大勢の人が心のどこかで何かおかしい、何かが欠けていると思っているようですが、たいていの人は責める対象を間違っています。Rubyで書いたアプリがとんでもない代物になったって？ それはあなたがきちんとテストコードを書かなかったか、テスト駆動開発（TDD）の指針に則って開発しなかったからです。もしくは、正しいデザインパターンに切り分けるための知識が不足してい
単体テスト（画面単位のテスト）がクソらしいので思ったことを書いてみる - うさぎ組
なんか2週間くらいずっと画面単位のテストを単体テストと呼んで、手動テストをする現場についていろいろ文句がSNSで流れていた。それについて思うことをバカスカ書く。 これは、誰かを批難したいわけでもなく、ただの感想である。言うなれば街の風景をみたときの日記だ。そうだよ。これは日記だよ？ 要約 だいたいの話は僕が2,3年前にTwitterで言いまくった単体テスト/結合テストなんて存在しない - Togetterまとめに似ていると思ったけど、僕の狭い観測範囲では生産的な結論を迎えずに文句の固まりで終わって、こう非常にあーあっていう気持ちが残った。 あと、観測結果として 同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの？ねぇ？なんで？」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。 というのが大きかった。 単体テスト まず、最初に思ったのはTwitterで文
効果の高いテストについて考える - gong023の日記
テストエンジニアという奇異な立場にいる。 普通にプロダクトメンバーの一員だが、プロダクト自体のコードはあまり書かず、品質という観点から良かれと思ったことをする。大体グーグルのテスト本に載っているSETをロールモデルとしている。 テストから見えてくる グーグルのソフトウェア開発 作者: ジェームズ・ウィテカー,ジェーソン・アーボン,ジェフ・キャローロ,長尾高弘出版社/メーカー: 日経BP社発売日: 2013/05/23メディア: 単行本この商品を含むブログ (8件) を見る SWTは、例えばエンジニアがテストを書きやすいようにライブラリを作ったり、テストがリリースのネックにならないように高速化したり、手動テストを支援するようなサポートツールを作ったりするのが役割となる。普通に単体テストも書く。（が、それはあまり理想ではなくて、本当はそのコードを書いた人が単体テストも書くべきだ。） しかし、現
Javaのモックアップフレームワーク「mockito」でリクエスト／セッションを再現する
しかし、開発推進セクションとしてリーダーを中心に「基本的には必須ですが、相談には乗ります」と伝えてきました。もちろん、こちらとしても妥協することはありますが、基本は書いてもらうように言い続けたことは良かったと思います。今ではテストケースは2,000ケース以上となり、毎日jenkinsからもallTestの結果が送られてくるようになったのですから。そんなやりとりをしていく中で、こんなFAQも生まれました。 Q：巨大なメソッドで1行だけ修正したのですが、そのメソッド内をすべてテストしないといけないの？ A：基本はテストしてください。 ただしトラブル対応など、どうしてもすぐにリリースしないといけない場合はその限りではありません。 結果的にこのようなFAQは、開発メンバーにJUnitの導入を受け入れてもらうために必要なことだったと思います。やはり、開発スピードを重視するチームにとって、やることが多
テスト駆動型開発についての議論 - ワザノバ | wazanova
http://blog.testdouble.com/posts/2014-01-25-the-failures-of-intro-to-tdd.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約7時間前 Test Double社がブログで、TDD (テスト駆動型開発) を教える場合のアプローチを提案しています。 TDDについて、同じ用語やツールを使っていても、「モックオブジェクトがありすぎて、ひどい。」「モックオブジェクトがあふれていて素晴らしい!」という異なる見解に至るケースがでてしまっているのは、理想的なゴールに至る道筋を統一したかたちで教えきれてないからだと指摘しています。 TDDの一番の効果はコードのデザインの改善であり、コードのクオリティの担保は、うまくいけば二次的な効果、まかり間違えば幻想
アクセルを踏むためのテストとブレーキを踏むためのテスト - yoshiori.github.io
Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。 テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね！ で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。 で、早速なんだけど上記ブログから引用させてもらうと まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだ
Post by @shyouhei
俺は江島氏ともきょん氏とも面識はないですが、お二人ともが俺のことを知ってることを俺も知ってる程度には狭い業界であり。どちらかに肩入れしたいわけではないです。喧嘩したいわけでもないです。普段あまりここでは言及しないですが俺は今の仕事としてはテストを書いたりテストを実施したりする係をしてノリクチをしのいでおり、いわばテストは本業ですので、テストに言及することは今現在の同僚に対して意図しない受け取られ方をする可能性があるので困るので、それもあって普段はここではあまりテストの話はしないわけだが、だからと言って沈黙を破ってテストの話をするのが同僚に対して含みがあるというわけでもないです。とはいえ俺は大学等で真面目にソフトウエア工学の講義を受講したことがなく、経験と勘と昔取った杵柄だけで食ってるので、そういう意味では若干の後ろめたい気持ちもある。 俺が現職に転職してきて一番びっくりしたのはなんといって
最近行ったTDDの講演や寄稿について - t-wada の日記（旧）
こんにちは、だんだんブログ勘を取り戻していきたい和田です。このエントリは TDD Advent Calendar 2013 の 11 日目のエントリです。このエントリでは、最近行ったテスト駆動開発関連の講演や寄稿に関して、この機会にまとめておきたいと思います。 DevLOVE 現場甲子園 まず 11/9 にDevLOVE現場甲子園2013にて「テストを書く文化を育てる戦略と戦術」というタイトルで短い講演をさせて頂きました。DevLOVE 甲子園は楽天第2タワー大広間の四隅で最大四つの講演が同時に行われるという意欲的なイベントで、話す方も気合い(と声量)が必要な場でした。 この講演では、開発者が自動テストを書く文化が無かった組織に自動テストの文化を育てる際の姿勢、心がけについて短い時間でまとめました。そのときの講演資料がこちらです(ライセンスは CC BY です)。 テストを書く文化を育てる
テストを書く文化を育てる戦略と戦術
at DevLOVE現場甲子園2013 2013/11/09 (土) http://http://devlove.doorkeeper.jp/events/5464
UIマッピングを使って、Selenium IDEのテストスクリプトを効率よくメンテナンスする | MagicPod Blog | MagicPod: AIテスト自動化プラットフォーム
「name=your-name」「css=input.button」のような、操作対象の画面要素を特定するための記述(「ロケーター」と呼びます※1 )が、何箇所にも分散しています。 「UIマッピング」とは、この分散したロケーターを、UIマップファイルという1つのファイルで集中管理する手法です。(図2) ロケーターに「inputName」「buttonSearch」などのわかりやすい別名をつけ、テストスクリプト中ではロケーターでなくこの別名を使用します。 UIマッピングを行うと次のようなメリットがあります。 画面のHTMLが変わった場合に、UIマップファイル中のロケーターだけを書き換えればよいので、メンテナンスの手間が大きく軽減されます。 わかりやすい別名を使用することでテストスクリプトが読みやすくなります。 ちなみに、UIマッピングをさらに洗練させたページオブジェクトデザインパターンという
oreilly.com
Build the skills your teams need Give your teams the O’Reilly learning platform and equip them with the resources that drive business outcomes. Click on a feature below to explore. Trusted content Live online events Courses Interactive learning Certification prep O’Reilly Answers AI Academy Assignments Insights Dashboard Trusted content you can count on More than 60K titles from O’Reilly and nearl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発者向けのテストの本いろいろ
开门红-满江红！