All slide content and descriptions are owned by their creators.
![ZOZOTOWNシステムリプレイスの道のり/ ZOZOTOWN 更换云系统之道 - Speaker Deck](https://cdn-ak-scissors.b.st-hatena.com/image/square/c2d4b5d977ce08dce8f3c17856677d7bcfab1c54/height=288;version=1;width=512/https%3A%2F%2Fspeakerd.s3.amazonaws.com%2Fpresentations%2F6dc784c47a6949bdb6cb72fbd9a07ff8%2Fslide_0.jpg%3F461051)
All slide content and descriptions are owned by their creators.
2019/07/26 追記 2019年7月26日、はてなダイアリーからはてなブログへの自動移行が完了し、はてなダイアリーでの記事の公開が終了いたしました。詳しくは下記の告知をご参照ください。 diary.hatenastaff.com 本文 株式会社はてな サービス・システム開発本部長の大西(id:onishi)です。平素ははてなダイアリーをご利用いただき、誠にありがとうございます。 はてなでは現在、「はてなダイアリー」と「はてなブログ」という2つのブログサービスを提供しておりますが、はてなダイアリーを2019年春をめどに終了し、はてなブログに統合いたします。 はてなダイアリーユーザーの皆さまには、さまざまな機能が進化し、より安全・便利にご利用いただけるはてなブログへの移行を、ぜひお願いしたいと思います。 私は、エンジニアとして「はてなダイアリー」の開発に携わり、ディレクターとして「はてな
はじめに 前回 akito0107.hatenablog.com どちらかというとこっちが本編。 前回の記事ではTest Sizesについて紹介したが、今回の記事はその分類が実際の開発にどう役に立っているのかをまとめたいと思う。もちろん用語の統一も大きな意味を持つが、それ以外のことを書いていきたい。 具体的には、CIでテストのパイプラインを組む時にこの分類どおりに組んでいくと綺麗に整理でき、CI全体のスループット向上にも効果がでているという話だ。今回の話は僕たちのチームに特化した内容になるが、1) Test SizesごとにTestの起動コマンドを分ける、 2) Smallから順に実行していき、落ちるべきテストはできるだけ早期に落とす、というポイントはどこにでも使えるものだと思う。 コンテナ技術とテスト 僕たちはローカルの開発環境だけではなく、本番環境やCI環境でコンテナ技術(主にDock
はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類(small / medium / large)に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く