バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなメソッドは emptyIfNull です。 僕は、自社クラウドである cybozu.com のミドルウェアを開発するチームで働いています。具体的には、検索サービスやファイルサーバー、非同期処理用ワーカー、セッションマネージャーなどなどを提供しています。 僕がこのチームに来たのは数年前ですが、当時はバグの多いプロダクトでした。今はすべての既知のバグを直し、残存不具合件数が 0 件、つまりバグゼロな状態になりました。また、バグゼロを実現してから 2 年ほど経過していますが今もその品質を保っています。今回はこのバグゼロを実現した方法と、その後の顛末について記そうと思います。 以前のコード 数年前に提供されていたこのミドルウェア群は、はっきり言って、バグの塊のようなプロダクトでした。 当時のコードは保守性とは程遠い
git rm -r spec
ThumbnailsDocument OutlineAttachmentsFind:PreviousNextHighlight allMatch casePresentation ModeOpenPrintDownloadCurrent ViewGo to First PageGo to Last PageRotate ClockwiseRotate CounterclockwiseEnable hand toolDocument Properties…Toggle SidebarFindPreviousNextPage: Presentation ModeOpenPrintDownloadCurrent ViewToolsZoom OutZoom In More Information Less Information Close Enter the password to open t
テストなんか書かなくて良い！？ エンジニアたちの反応まとめ
リンク http://mosa-siru.hatenablog.com/ テストなんか書かなくて良い 僕の考えるサービス開発の肝 - mosa_siru’s blog 世の中は一周まわってエンジニアリングの手法に溢れている。 テストを書け、ドキュメントを書いて冗長化しろ、コミットはわかりやすく、コーディング規約が、安定性が─── でも、それって本質なんだろうか？ 新規サービスを作る際に肝だと思っていることをまとめてみた。 おことわり 以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定
WebdriverIOならyieldでテストが書けるぞ！！！！！！！！ - マルシテイア
先日、JavaScript用E2EテストツールWebdriverIOの新バージョンがリリースされました！ webdriver.io WebdriverIO E2Eテスト用WebDriverのラッパーです 僕は↓の記事で知りました motemen.hatenablog.com Protractorとかと比べて比較的シンプルだった印象だが今回は……？？？ 新機能 今回のバージョンの目玉機能はこちら テストランナー wdio yieldでテストが書ける テストランナー wdio WebDriverIO の略ですね karmaと同じく、wdiio.conf.jsでブラウザ、フレームワーク等を指定する感じです wdio.conf.jsにSauce Labs, Browserstackのアクセスキーを書くことでこれらのサービスを簡単に使えるみたいです あとmochaのオプションも埋め込める（mocha
GoでEnd To End Testingフレームワーク書いた - Webtech Walker
SeleniumラッパーなテストフレームワークをGoで書いてみた。初Go。 https://github.com/hokaccha/sprinkler GoのコードでE2Eテストのコード書けてもあんまり嬉しくないのでYAMLで書けるようにした。 scenarios: - name: Hello sprinkler! actions: - visit: http://www.google.com - assert_title: Google - wait_for: input[type="text"] - input: element: input[type="text"] value: Hello - submit: form[name="f"] - wait: 1000 - assert_text: element: "#main" contain: Hello こんな感じのYAMLを以
えっ、私のテストカバレッジ、低すぎ…？ - いま作ってます。
まとめ テストの「カバレッジ」には、C0, C1, C2の3レベルが存在する 一般的なカバレッジ測定ツールはC0しか測定できない C0だろうがC2だろうが、カバレッジは目安にしかならない とはいえ、他に目安になる物は何もないので、見ないよりは見た方がいい 序 しばらく前のShibuya.js*1が面白そうだったので指をくわえながらIRCで後輩に一席ぶった「テストカバレッジの罠」について書いておくよ。 FizzBuzzのテスト 以下のようなコードを考えよう*2。 <?php function fizzbuzz($i){ $return = ''; if( $i % 3 === 0 ) $return .= 'Fizz'; if( $i % 5 === 0 ) $return .= 'Buzz'; if( $i % 3 !== 0 && $i % 5 !== 0 ) $return = $i;
不必要なテスト - パルカワ2
テストするべき項目、テストするとき考えると思う。 一つのメソッドに対して、テストするべき項目が多すぎるとそのメソッドがやたらでかいとか、不必要な部分までテストしてるとかだと思う。 メソッドがやたらでかい場合は、切り分けるし、不必要なテストは、消すべきだと思う。 あるパラメータからデータを作って、さらにそのデータを使って計算するみたいなの全部まるっと一つにまとめるとかよくされる。何をしているかで分類すると2つやってることがある。メソッドは、一つのことをやればいいと思う。だから、あるパラメータからデータを作るメソッド、データを受け取って計算するメソッドみたいな感じで分けるのが良いと思っている。 sub hoge { $self->fuga() # hoge処理 } 不必要なテストは、こういうhogeメソッドがあったとして、fugaのテストまで、hogeのテストでやってしまうみたいなの見かける。
アクセルを踏むためのテストとブレーキを踏むためのテスト - yoshiori.github.io
Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。 テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね！ で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。 で、早速なんだけど上記ブログから引用させてもらうと まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだ
プログラムに証明が付く日 | RANDMAX
この記事は「Theorem Prover Advent Calendar 2013」6日目の記事です。 http://qiita.com/advent-calendar/2013/theorem_prover 神田「野らぼー」にて、地下の薄暗い店内で… 「そう言えばこないだ隣で起こってたポインタオーバーラン、対応大変そうだったですけどちゃんと家に帰れてたんでしょうかね、新婚なのに…」 「ヌルポとかポインタオーバーランとか、どうして無くならないんだろうね。その時はみんな手を抜いてるつもりなんて毛頭なくて、一生懸命考えて大丈夫だと思ってるはずなんだけどね。レビューもして、それでも起こった後でみんなでソース見てみると、なんで気づかなかったんだよ！ってことになる。」 「人間って、そういうの苦手なんでしょうねきっと。ほら、『何かほかにありませんか』って聞かれても出てこないじゃないですか。静的な解析っ
Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記
テストを書く目的 自分の書いたコードが意図した通りに動いてるか確認するために書くのですが、自分が楽をするためと他の人のために書いてます。 自分が楽するため Webアプリの場合、実装した機能がちゃんと動作するかを確認するために何度もブラウザポチポチしてというのは時間がかかります。なのでその回数をなるべく減らすためにテストとして書けるところはなるべくテストで確認して、ブラウザポチポチする回数を必要最低限にしたいと思っています。 ブラウザポチポチするのも立派なテストだと思っています。再現性のない。 他の人のため テストがないと他の人がその機能に関連する機能を変更しようとした時に変更の影響がないのか確認することが出来ず、その機能に対するテストを手動で行わせてしまうことになってしまいます。 テスト書く時間がない問題 テストの話をすると書く時間がないと言われたりしますが、既存の開発の流れにテスト書くこ
初めから厳密すぎるテストを書くのは筋悪なのではないかという話 - 愛と勇気と缶ビール
これは人それぞれのコードの書き方に依存するので必ずしも筋悪というわけではない。むしろそういう風に書いてしまえる人もいるだろう、くらいの話。 何が言いたいかというと、自分の場合、ある程度は頭の中でまとめつつとりあえず手を動かして書いてみる→気に入らなかったり、後から「これではあかん」と思ったらインタフェース変える、みたいなことを繰り返しながら、要は同時にリファクタリングしながらコードを書いていくので、初めから厳密すぎるテストを書いてしまうと手戻りが多くなって非効率的なのである。 例えば、とあるJavaScriptのメソッドの返り値がこんな感じだったとしねえ。 { valid: true, foo: 10, bar: 0 } で、"valid"の部分はほぼ間違いなくこれで行くけど、"foo"と"bar"の部分は後から無くすかもしれない。あるいはkey名を変えるかもしれない。あるいは何か別のke
FINDJOB!終了のお知らせ | FINDJOB!
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
Test-Pretty - Prettify the Test::More's output - tokuhirom's blog
Test::Pretty is a prettifier for Test::More. When you are writing a test case such as following: use strict; use warnings; use utf8; use Test::More; subtest 'MessageFilter' => sub { my $filter = MessageFilter->new('foo'); subtest 'should detect message with NG word' => sub { ok($filter->detect('hello from foo')); }; subtest 'should not detect message without NG word' => sub { ok(!$filter->detect('
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編） ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか？ 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
ryuone日記(2012-06-07)
■ [JavaScript][Sinon.JS]Sinon.JSのstubについて Sinonのstubに関するドキュメントはここです。 そもそもstubとは Test stubs are functions (spies) with pre-programmed behavior. They support the full test spy API in addition to methods which can be used to alter the stub's behavior. As spies, stubs can be either anonymous, or wrap existing functions. When wrapping an existing function with a stub, the original function is not calle
JSの単体テストにJsTestDriverがおすすめ
基本的には以下の内容のまとめです。 0-9, JsTestDriverを使うときの注意点 http://0-9.tumblr.com/post/15574052397/jstestdriver 0-9, 最近のJS系のツールを触ってみたまとめ http://0-9.tumblr.com/post/15398953814/javascript-tools ・JsTestDriverとは何か？ 超簡単に言うとSelenium CoreのJS実装とQUnitを合わせたものです。 実際Selenium ver2はJsTestDriverが使ってるWebDriverと言うAPIを使っています。 （WebDriverがブラウザを外部から動かす共通仕様で、Selenium ver2とJsTestDriverはそれを使ってる状態） ・使った感想は？ ブラウザ上で動作するJSの単体テスト環境としてはかなり快
Sinon.JS - Standalone test fakes, spies, stubs and mocks for JavaScript. Works with any unit testing framework.
Standalone test spies, stubs and mocks for JavaScript. Works with any unit testing framework. Get Started Star Sinon.JS on Github Get Started Install using npm To install the current release (v18.0.0) of Sinon: npm install sinon Setting up access Node and CommonJS build systems var sinon = require("sinon"); Direct browser use <script src="./node_modules/sinon/pkg/sinon.js"></script> <script> // Ac
Testing Web Application 2011秋 - tokuhirom's blog
とにかく楽に、お気軽に。お気軽にテストを追加できて、お気軽にテストを実行できる。というのがなによりも重要です。 追加しようとおもったときに「どう追加したらいいかわからない」という状況になりがちなので、あらかじめいろいろな構成要素ごとにテストをひととおりかいてみるというのも重要だとおもいます。O/R Mapper のクラスのテストとか、model のテストとか、コントローラのテストとか、JSON API のテストとか。。 ExtUtils::MakeMaker でテストをうごかさないExtUtils::MakeMaker を素でつかうと blib/ とかつかってきてうざいので、Makefile.PL に以下のような hack をほどこしてあります。ウェブアプリケーションで blib/ とかにコピーする必要ないですよね。実運用でも blib/ でうごかさないし、インストールもしませんし。 #
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テストから見えてくるGoogleのソフトウェア開発 - mattak's blog