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…
組織にテストを書く文化を根付かせる戦略と戦術（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
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と相対するドリームマッチが開催された。この会談の
テスト駆動型開発についての議論 - ワザノバ | 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 です)。 テストを書く文化を育てる
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発者向けのテストの本いろいろ