テストを書かない言い訳をさせてくれ
iOS Test Night #3 - connpass https://testnight.connpass.com/event/49561/ での発表資料です。 👉続き https://speakerdeck.com/takasek/tesutowoshu-kanaiyan-iyi-wositajie-guo-wwwwwww 参考リンク: レガシーコード改善ガイド（ウルシステムズ株式会社 平澤章 マイケル・C・フェザーズ 越智典子 稲葉信之 田村友彦 小堀真義） ｜ 翔泳社の本 http://www.shoeisha.co.jp/book/detail/9784798116839 Stable Dependencies Principle http://wiki.c2.com/?StableDependenciesPrinciple%60 PHP7 で堅牢なコードを書く - 例外処理
Googleのテスト自動化の進化 - ワザノバ | wazanova
https://www.youtube.com/watch?v=6ZvCU0dht50 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Google Test Automation Conferenceが今年はSeattleで開催されたようです。その中で興味深いと感じた話題をいくつか拾ってみました。 1) 成長を続けるGoogle 会社の規模が大きくなり、歴史を重ねてくると、何事も非効率になりがちですが、Ankit Mehtaが紹介してくれた数字によると、Googleの開発ペースは依然として右肩あがりのようです。 コードのコミットは、1日3万チェックイン。約3秒に1回。グラフを目測した限りでは昨年から約20%増。 リリース数もこの1年でほぼ倍増。 2) テストクローラーを利用してのモバイル実機テストの
「Javaの鉱脈」でGatlingの記事を書きました | さにあらず
WEB+DB PRESS の Vol.83 で、負荷テストの記事を書いたので是非読んで頂きたい。 2014/10/24 発売ですので、既に購入頂いてる方も多いと思います。 電子書籍版もありますので物理的な媒体に興味がない方は PDF を買って下さい。 WEB+DB PRESS Vol.83@Gihyo Digital Publishing今回の記事における対象読者について#JMeter だ、JMeter を撃滅せよ。 負荷テストスクリプト書くのに GUI なんぞいらないのですよ。 素人騙すんなら、それでいいかも知らんけども、そういう事じゃないでしょう。 GUI なしでも書けますよって、そのヤヴァイ XML を俺に見せるな。 負荷かけてる最中にサーバより先に死んだりするような負荷テストツールを後生大事に使うのをやめて欲しいのです。 今回は、新進気鋭のツールであるところのGatlingを紹介し
テスト駆動型開発についての議論 - ワザノバ | 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の一番の効果はコードのデザインの改善であり、コードのクオリティの担保は、うまくいけば二次的な効果、まかり間違えば幻想
なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog
ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript
テストをどこまで書くか - はこべにっき ♨
CROSS2014で以下の2つのセッションにお招きいただきお話をさせていただいた。ありがとうございました。 http://www.cross-party.com/programs/testcidevops/ はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey 2014/1/17 #cross2014 現場に聞く！テスト/CI/DevOps、実際のところどうなの - Togetterまとめ http://www.cross-party.com/programs/butsukari/ 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetterまとめ セッション中はもちろん、その後の懇親会でもいろいろな方におはなしを伺えてかなり勉強になった。テストやコードレビ
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
FINDJOB!終了のお知らせ | FINDJOB!
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー
一昨日 Testing Casual Talks #1 に参加した。名前の通り、ソフトウェアテストに関するカジュアルなカンファレンス。とても面白かった。すこし思ったところを書いていこう。 テストのエンジニアリング トップバッターの @ikasam_a さんの発表では Software Engineer in Test at DeNA ということで、氏が勤務先でテストエンジニアリング部門を立ち上げていくにあたってのいきさつや背景といったところが述べられていた。 テストは開発者の生産性を向上するためにある、生産性向上のためにテストを書くテストエンジニア、近年複雑化するテストの実行環境を構築するのもテストエンジニアの役目、"Testing Activities SHOULD be in Developments" ─ テスト活動は (従来型のQAのように開発の外ではなく) 開発の中で行われるべき
テストを書きましょう、という話はもっともだと思うのだけど - 聞かれてもいないことを喋る
テストを書きましょう、という話はもっともだと思うのだけど、テストを書けばバグのないリリースができるかといえばそんなことはない。テストで保証できるのは、自分が認識している仕様が正しく満たされていることであって、逆にいうと自分の想定から漏れているものは網から外れる。ここからバグが生まれる。 テストの不足によるバグと考慮漏れによるバグは自分の感覚では2:8くらいな気がする。テスト戦略にまつわる議論がここまでされるのだから、考慮漏れをいかになくすかという議論は、もう少しされても良いのかなぁという気がした。 今パッと思いつく限りで考慮漏れを根絶する方法をリストアップしてみる。 検証項目を脳内に持たずどこかに書き出し、それを誰かにレビューしてもらう。 毎度イチから検証項目を考えるのでなく、共通する検証項目はどこかに書き残しておき、それをベースに作成する。 動作チェックを第三者にやってもらう。 …ああそ
require.js 環境で mocha + expect + testem を使った JavaScript テスト - naoyaのはてなダイアリー
先日書いた自分用アプリケーションのひな形 http://d.hatena.ne.jp/naoya/20130503/1367581629 http://d.hatena.ne.jp/naoya/20130504/1367640512 これに、JavaScript のテスト環境も追加したい。 結論からいくと、フレームワークには mocha + expect、ランナーは testem を使うことにした。ついでにテストダブルライブラリとして Sinon.js も有効にした。 ちなみに今回の文脈は End to End のテストではなくてユニットテスト周りのおはなしです。 mocha + expect JavaScript のこの辺のテスト周りは今もいろいろなツールの整備が進んでいて、今回採用した以外にも Jasmin や QUnit そのほか色んな物がある。昨今の状況に関しては 先日の HTML
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JavaScriptでWebDriverのテストコードを書きましょ
IBM Developer