テストコードを負債化させない上手な付き合い方 / Test Code ManagementXUnit Test Patterns に筆者の経験則を落とし込んでまとめています。 2024/01/25 TechBrew in 東京 〜技術的負債と共に歩むプロダクトの成長〜 の登壇資料です。 https://findy.connpass.com/event/306451/
新卒１年目が荒れ果てた開発環境に１年間でCIを導入し単体テストを布教した話 - Qiita
この記事は 「Develop fun!」を体現する Works Human Intelligence Advent Calendar 2020 21日目の記事です。 昨日の記事は@sparklingbabyさんのStream API がもっとわかる記事でした。 あらすじ 私は2019年にWorks Human Intelligence（正確には分社前の会社）に新卒入社し、 19年10月からプロダクト開発部門に配属され、SETエンジニアとしてとある製品のJava開発環境の改善に取り組んでいます。 ざっくりとプロダクト開発を紹介するとこんな感じです。 3万クラス程度ある大規模Java Webアプリケーション 開発環境はEclipseを使用 開発者のOSはWindowsのみ Before 私が開発チームに参加した時点では 部門として新規開発に注力しており、足下の環境改善をやる担当者がおらず、 い
DBアクセスで遅くなったテストの実行時間を Docker で 40% 削減した方法 - Qiita
DBのレイヤーを含むエンドツーエンドテストやDBに依存したコンポーネントの自動テストがたくさんあると、全てのテストが終わるまでに長い時間がかかるようになってしまうことがあります。DBのクエリ実行はネットワークIOやディスクIOなどを含んだ高コストな処理だからです。 Docker を少し工夫して使うと、お手軽にテスト中のDBのクエリ実行にかかる時間を削減できます。自動テストが完了するまでの待ち時間を短縮し、開発のフィードバックサイクルをより早く回せるようになります！ MariaDB を用いたプロジェクトの実績では、DBアクセスを伴うテストケースが 153件 ありましたが、この方法によりそのテストスイートのローカル環境での実行時間を約 43% 削減できました（約 145.7s → 約 83.3s）。 どうやって？ Docker で tmpfs を使います。 tmpfs tmpfs とは、ディス
t-wadaさんから直接学ぶ！TDDワークショップ開催レポート - pixiv inside
みなさんこんにちは！ピクシブで唯一(?)のテストエンジニアの @shimashima です。 6月28日にTDDの伝道師として有名な t-wada こと和田卓人さんを講師として招き、1日かけてのテスト駆動開発(以下TDD)ワークショップを開催しました。 本日はピクシブ株式会社様にて、1日コースのテスト駆動開発ワークショップの講師を務めさせていただきました。ご参加くださいました皆様、誠にありがとうございました！— Takuto Wada (@t_wada) 2018年6月28日 今日はその様子を紹介したいと思います。 開催のきっかけ 開催のきっかけは、自分が実行委員を務めているJaSST '18 Tokyoにて和田さんによるTDDチュートリアルを聞いたことです。 このチュートリアルの登壇依頼を行なったのも私なのですが、恥ずかしながらそれまでTDDは話に聞いただけで、各地で開催されているTDD
CircleCI 2.0でのスローテスト（テスト遅い）問題対処法を思いつくだけ書き出す - Qiita
まえおき スローテストの解消に関して、昨今のCIサービスを考慮した観点で自分なりの手法をまとめてみる。 CIで出来そうなことは可能な限り網羅したつもりだが、他にもあったらコメントか編集リクエストでご指摘いただきたい。 とりあつかうこと・とりあつかわないこと CircleCI 2.0 を前提とする。 1.0はもうすぐ無くなるので対象外 他のCIサービスは今回対象としてないが、一部似たような機能があるかもしれない。 テストフレームワーク固有の話はなるべく排除している サンプルコードがnodeだったりrubyだったりで統一取れてないのはご了承いただきたい。 dockerモードを前提とする。machine: trueでの実行は検証していない 検証してないだけなので、もしかしたら動くものもあるかもしれない CIではなくCD（継続デリバリー）に特化した話は除外する 転用できる部分はあるものの、あまりフ
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
無法地帯にテストケースを追加する時にいつもやっている戦略 - laiso
数年開発続いてるけどテスト全くないみたいなよくあるコードベースを想定。 不具合を修正する時についでにリファクタリングしてドメイン層のテストを書く。 手動テストで不具合を再現 ViewからロジックをControllerへ移動し、Viewからは値の参照のみにする 移動したロジックをController内でプライベートメソッドに切り出す。返り値を(2)の値にセットする プライベートメソッドを外に出して関数→モジュール化する (4)のメソッドに対してテストを書き、失敗するのを確認する ポイントとしては 運用的観点ではなるべく早く不具合を修正してデプロイしたいので、リファクタリングだけ別のブランチでゆっくりやる 依存がでか過ぎで解決できなさそうなど問題があれば、その時点ではテストを書くのを諦める。行動したことで学んだIssueを起票する 具体的なリファクタリング方法は レガシーコード改善ガイド (O
市場バグを引き起こした優秀なデータたち - ボドゲを愛するテスト屋さん
※この記事は「ソフトウェアテストの小ネタ Advent Calendar 2017 - Qiita」用の記事です。 ソフトウェアテストの小ネタ 2日目担当のオムそばです。 実はちゃんとした(?)記事を書くのはこれが初めてなので、生暖かい目で見ていただければ。 そんなわけで早速表題の件、市場バグを引き起こした優秀なデータたちをご紹介します。 今回は、よくある「半角記号」、「空白やスペース」などは割愛させていただきます。 (2017/12/26追記)"市場バグ"という言葉に違和感や疑問を持たれた方は、こちらの記事をどうぞ。文言について整理してみました。 ■日時に関するデータ ・1969/12/31、2038/1/20：UNIX系のシステムに有効なデータ。UNIXのシステム時刻は1970/1/1 開始なので、それ以前のデータを打ち込むと予期せぬエラーが発生する可能性がある。また、同様に2038/
TDDはあんまり使わなくなったけど心の中にある - Mitsuyuki.Shiiba
今日は娘たちとコログ探しして楽しかった。 この数年間、頭の中にTDDを入れた状態で開発をしてきたんだけど。タイトルに書いた風に思う。 良い所がいっぱいある 見失わずに済む 僕にとってTDDの良さは、まず、自分が何をしようとしているかを見失わずに済むところ。一歩先にゴールを立てて、そこに向かって一歩進む、たどり着いたら、次の一歩を進める。その繰り返し。だから、遠く離れたゴールに対して、急いで走って、途中で道に迷ってどこに向かってるか分かんなくなったりしないで済む。 余計なものを作らなくて済む 「必要なものはこれだよね？」という確認から入って、それを実現するための実装に集中するから余計なものを作らなくて済む。実装を先に作ると「こういう機能もあるといいかもだから入れとこうかな」ってついつい入れてしまう。 リファクタリングできる まず最初に動くものを作ってから、その状態をキープしたまま、実装の改善
開発を効率化するテストのデザインパターン
2017/3/13 iOS Test Night #3 https://testnight.connpass.com/event/49561/
PICTでテストケースの組み合わせ爆発にさよならを - エンジニアをリングする
Goodpatch Advent Calendar 2016 13日目の記事です！ わたしはGoodpatchでProttというプロトタイピングツールのWebフロントエンドの開発を担当しています。 Prottでは、プロトタイプの再生に関する修正をしたあとは必ず全動作を網羅したテスト用プロジェクトでの動作確認を行っています。 ただ、すべての環境や条件を揃えた上でのテストにはなかなかの工数がかかってしまっていました。 この記事では、オールペア法という手法とPICTというCLIツールを使用してテスト工数を半分以下に削減した方法を紹介します。 単純に全組み合わせ 推奨環境としているOSやブラウザと3種類の再生モードを組み合わせると、テストすべき組み合わせは全部で20パターンになります。 （プレビューモードとプレゼンテーションモードは対PC、スタンドアロンモードは対モバイルのモードです。） - Ma
一から始めるJavaScriptユニットテスト - Hatena Developer Blog
この記事は、はてなエンジニアアドベントカレンダー2016の5日目の記事です。 こんにちは、はてなでアプリケーションエンジニアをしている id:shiba_yu36 です。先日、buildersconにおいて、現在所属しているプロジェクトでJavaScriptのユニットテストを導入した知見について、「一から始めるJavaScriptユニットテスト」というタイトルで発表しました。 speakerdeck.com この発表は、実際にJavaScriptのユニットテスト環境を作ってみると非常にハードルが高いと感じたので、そのハードルを少しでも下げられればという思いで、非常にシンプルな例で一から環境を作る例を紹介しました。アジェンダは次のとおりでした。 カクヨムのJS環境 JSのテストツールを整理する 通常の関数のユニットテスト DOM操作する機能のユニットテスト カクヨムのJS環境や、JSのテスト
テスト自動化の様々な道具を使ってみた四方山話
8. Selenium WebDriver 一番低レベルな実装でこれでできない操作は他の でもできない public class BingTest {//ドライバーのセットアップとかは省略 @Test public void title_of_bing_should_contain_search_query_name() throws Exception { driver.get("http://www.bing.com"); driver.findElement(By.id("sb_form_q")).sendKeys("automation"); driver.findElement(By.id("sb_form_go")).click(); assertThat(driver.getTitle(), containsString("automation")); } } (´・ω・｀)
ブレークポイントを使ったJavaScriptデバッグを整理してみた【再入門】 - Qiita
はじめに プログラミングの上達において、デバッグスキルを上げることはとても重要で近道の1つだと考えています。 私自身、勉強し始めた頃に知っていれば（理解できていれば）とよく思います。 今回、JavaScriptデバッグについてChromeDevtoolsとブレークポイントを使った基本パターンを整理しました。 自身の復習かつ、あまり馴染みの無い方でも、以下おおよそ理解できるようになれば良いなぁ、というのが本稿の目的です。 どのようなものにブレークポイントが貼れるのか どういった時にブレークポイントが発動されるのか ブレークポイントが発動されると何ができるのか ご存知の方には特に目新しいことはないかと思いますが、何かのお役に立てば幸いです。 表示・動作はChrome 50.0.2661.87mで確認したものになります(2016-05-11) タブやパネルの位置は環境によって異なる可能性がありま
組織にテストを書く文化を根付かせる戦略と戦術
1. The document discusses various social media and video sharing platforms and tools for integrating them, including YouTube, Twitter, Flickr, iTunes, and Facebook. 2. It mentions several services that allow embedding or sharing content between platforms, such as CDTube for YouTube, ZonTube for Amazon, and amz.ly for shortening Amazon URLs for Twitter. 3. Programming languages and APIs mentioned i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サイボウズが行うフロントエンドの品質保証 / Frontend Quality Assurance at Cybozu
ユニットテストのアサーション 流れるようなインターフェースのAssertJを添えて 入門者仕立て
PHP7 で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016
Testable Lambda: Working Effectively with Legacy Lambda
TypeScript + mocha + power-assert-js + Sinon.JS テスト環境メモ - Qiita
