テストコード品質を高めるためにJS向けMutation Testingライブラリ・Strykerを実戦導入してみた
はじめに 株式会社hitocolorのKanonとしてはお初にお目にかかります。実は2024年2月からhitocolor様に副業先としてジョインさせていただいてます。 hitocolor様ではkokoroeというeラーニングサービスの開発をお手伝いしています！ hitocolor様にjoin後、最初に着手した本格的な案件が今回の記事で書くStrykerの導入です。 Stryker自体は本業[1]の方の社内勉強会で登場したTOPICSで、その時から関心を持っていました。 本業の方ではそれよりも優先度の高いタスクがたくさんだったので導入の目処がなかったのですが、hitocolor様の方で提案したところ「いいね！」とおっしゃっていただき導入する運びになりました。 そして導入にあたっていろいろやったことを、「せっかくなので記事として公開してみよう！」とお話をいただき今に至ります。 Mutation
【翻訳】テスト駆動開発の定義 - t-wadaのブログ
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2
(自分の) JavaScript のユニットテストの書き方
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
Infrastructure as Codeのつらみの原因を探れ 恐怖症による負のサイクルを断ち切る“予測可能性”
ソフトウェア開発、ITインフラ運用、そしてその境界線上にあるトピックをカバーし、特にDevOpsを実現するための自動化、テスト、セキュリティ、組織文化にフォーカスした「DevOpsDays」。ここでソフトウェアエンジニアのチェシャ猫氏が「Infrastructure as Code の静的テスト戦略」をテーマに登壇。まずはInfrastructure as Codeについてと、そのつらみから発生する“オートメーション恐怖症”を防止する方法を紹介します。 「コード化の“つらみ”をいかにうまく防ぐか」が今日のテーマ チェシャ猫氏：チェシャ猫と言います。Twitterは@y_taka_23の名前でやっているので、よろしくお願いいたします。今日は「Infrastructure as Code の静的テスト戦略」をテーマに選びました。Infrastructure as Codeはここ数年で、非常にメ
Windows環境で利用できるMicrosoft製負荷ツール
CPUに負荷を掛けるCPUに負荷を掛ける場合は、開発者・管理者向けのトラブルシューティングツール「Windows Sysinternals」で提供されている「CPUSTRES」を利用します。 ツールは以下からダウンロードできます。 CpuStres - Windows Sysinternals | Microsoft Docs ダウンロードしたZipファイルを解凍し、OS環境に応じたファイルを実行します。 32ビットOSなら「CPUSTRES.EXE」64ビットOSなら「CPUSTRES64.EXE」CPUSTRESを実行すると、次のような画面が表示されるので、必要な項目を選択することで、CPUに負荷を掛けることができます。 たとえば、2コアのマシンでCPU使用率を100%にしたい場合は まず、Thead1・Thread2を選択した状態で、右クリックメニューから「Activity Leve
AWSのフルマネージド型サービスを使ったソフトウェアの開発でローカル開発端末からアクセスキーの漏洩を防ぐためのテスト方法 | DevelopersIO
AWSアクセスキーセキュリティ意識向上委員会って何？ 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 本記事の想定読者 本記事ではフルマネージド型サービス=IAMを使ってアクセス制御を行うサービスと置き換えられます、これらを一切使わない開発(ALB, EC2, RDSのみなど)をしている方は対象外です 本記事はAWS上にソフトウェアを構築する開発者(主にバックエンドエンジニア)や開発環境を提供するプラットフォーマーを想定読者としています Typ
資産価値の高いテストを書くためにFabricateを使い始めました - BASEプロダクトチームブログ
Product Dev Divisionの川島（@nazonohito51）です。 BASEでは創業当時よりCakePHPによるWebアプリケーション開発を行っており、同時にそのテストも充実させてきました。ですがその過程で気づくのは、CakePHP標準の仕組みだけではテストを増やせば増やすほどテストデータの管理が難しくなり、テストをメンテナンスするのが困難になる問題でした。きちんと長期的にサービスを良くしてくれる資産価値の高いテストが書けるように、今回はその問題と向き合い、解決するために@sizuhikoさんの開発されたFabricateというライブラリを導入したお話を書かせていただこうかと思います。 BASEの直面した課題 CakePHP2のFixtureという仕組み 詳細は公式ページを参照していただきたいのですが、CakePHP2にはテストデータを作るためのFixtureという仕組みが
Microsoft、オープンソースの自動UIテストスクリプトツール「WinAppDriver UI Recorder」を公開
Microsoft、オープンソースの自動UIテストスクリプトツール「WinAppDriver UI Recorder」を公開：自動UIテストのスクリプトを簡単に作成できる Microsoftは、Windows 10対応のUI自動化サービス「WinAppDriver」の新しいオープンソーステストスクリプトツール「WinAppDriver UI Recorder」を公開した。 Microsoftは2018年6月20日（米国時間）、「Windows Application Driver」（WinAppDriver）コミュニティー向けの新しいオープンソースツール「WinAppDriver UI Recorder」（以下、UI Recorder）の公開を発表した。UI Recorderは、自動化されたUI（ユーザーインタフェース）テストのスクリプトを簡単に作成できるツールだ。 WinAppDrive
puppeteer + express + mocha で快適 TDD している話 - ジンジャー研究室
TDD という用語を使うとテストおじさんがやってきて、それはそうじゃないとか色々言い出すと思うんだけど、それが趣旨ではないので勘弁して欲しい。予防線ここまで。 Puppeteer でテスト Puppeteer が世間的にも個人的にもブームだ。ヘッドレス Chrome を操ってクローリングしたりスクリーンショットを撮ったり色々出来る。 github.com で、あれこれと遊んでいるうちにテストに使えるんじゃね？ということに気づいたので実践してみたら快適だったという話。ブラウザ操作してテストというのは昔から Selenium というのがあり、こちらはクロスブラウザで出来たりするんだけどまあ大掛かりでだるさを感じてしまう。メリットデメリットの比較はさておき、どうせならナウいやつを使ってみたい。よし使おう。 何をテストするか 普段から画面を見ながら開発しているので、どこに何が表示されているべきとい
PHPStorm10 + VagrantでPHPUnitテスト自動化の環境をつくる - Qiita
PHPStorm上でPHPUnitを実施するメリットとは？ PHPで開発した関数やクラスを単体テストするためのフレームワークとして「PHPUnit」があります。 PHPUnitは、一度テストのクラスを作成しておけば、あとはテストを自動化して繰り返し実行できるようになるので、人力で動作検証するよりも実装ミスやエラーの発見がしやすくなります。 単体テストフレームワークの選択肢として、以前はSimpleTestが主流でしたがバージョンアップが遅かったり、実行速度も遅かったりして、PHPUnitへの乗り換えが進んでいます。 PHPUnitはテストフレームワークの中では導入コストが低いので、PHPアプリのテスト自動化を検討している人はまずはPHPUnitの導入をおすすめします。 そして、PHPStorm + Vagrant環境で開発している人は、わざわざVagrantゲストマシンにログインせずともP
テストの数を減らそう！プリキュアで学ぶPICT - Qiita
ソフトウェアのテストはたいへんだなあ ソフトウェアのテスト、きちんとしてますか？最近は、スマートフォンやタブレットの普及に伴って、ユーザが使うデバイスの種類が多様化しています。 使われるOSやブラウザ、画面サイズの種類が増える中、プリキュア1の多様化も著しいですね。「プリキュアで学ぶワンライナーWebスクレイピング」で検証した通り、昨年までは43人、今年は「魔法つかいプリキュア」が加わることで、プリキュアの数は総勢45人になりました2。プリキュアはキャラクターによって専用デバイスを持ったり3、感情が昂ぶると常識を覆す事象を起こしたりするので、ITサービスを提供するエンジニアの方々は、ユーザ満足度向上のため、当然プリキュアがユーザになった場合も考慮した動作テストをされていると思います。 とはいえ、プラットフォームとプリキュアの組み合わせの数は、既にかなりの数です。全てのパターンを試すととても
和田(t_wada)さんに技術相談をしました - CureApp開発者ブログ
2016 - 11 - 07 和田(t_wada)さんに技術相談をしました 二週間ほど前にはなりますが、 日本のTDD( テスト駆動開発 )の先駆者である和田さん(t_wada)をお招きして、 技術相談会を行いました。 日頃、開発時に感じていた悩みを聞いていただき、 和田さんにビシバシと解決していただきました。 そこで今回は特に印象に残った、 不安定なテストとの付き合い方 フレームワーク 選定基準 品質保証のやり方 について書こうと思います。 不安定なテストとの付き合い方 私たちは、普段から不安定なテストに悩まされていました。 不安定なテストとは、 ローカルでは通るけどCIでは落ちる 遅くて タイムアウト になるときがある など、コードでなく環境によって結果が左右されるテストのことです。 この不安定なテストによって、開発に新しく関わった人に毎回同じような説明をしたり、説明をし忘れて不要な対
SpotInstanceとJMeterを使って400万req/minの負荷試験を行う | DevelopersIO
Apache JMeterのMaster/Slave構成 シナリオを用いた負荷試験といえばJMeterということで、使ったことがある方も多いかと思います。しかし、ほとんどの方は自分のPCを使ってやっている程度ではないでしょうか。最近は、スマホ連動のシステムが多くなってきていますので、1台のPCから負荷を掛けたとしても大した負荷試験になりません。そこで、今回はJMeterをMaster/Slaveのクラスター構成にしてドカーンと同時アクセスを行いたいと思います。 クラスメソッドの負荷試験の歴史 創業時から業務系のシステム開発が多かったことから、レスポンスは3秒以内でOKとか、ピーク時の同時ユーザは100名といった、緩い条件をクリアすれば良かったことが懐かしく思います。今は、ユーザ数・データ量・トランザクション数・トラフィック等が爆発的に増える可能性のあるプロジェクトも多く、負荷試験は必須項目
【実録ドキュメント】そのログ本当に必要ですか？
今回の概要 数人で利用しているときは、レスポンスが軽快だったシステムで、ユーザー数が増えてくると急激にレスポンスタイムが悪化する現象が発生した。現場から学ぶWebアプリ開発のトラブルハック 第2回で扱ったFull GCなどいくつか原因が考えられるが、本稿ではログ出力にまつわるトラブルをドキュメンタリー形式で紹介し、まとめとしてログ出力のパフォーマンスに関するTipsを紹介する。 今日もまた、突然電話が鳴り響く ある穏やかな朝、突然電話が鳴る。相手は結合テストの工程からパフォーマンステストで支援に入る予定のプロジェクトの担当者である。用件は「結合テストを20人のテスターで実施しようとしているが、レスポンスタイムが1分を超えていて、テストがままならない。早急になんとかしてほしい」 これだけの情報では、トラブルをハックすることはできないので、Webアプリの問題点を「見える化」する7つ道具をノート
CakePHP SimpleTest連携時のメッセージ文字化けを修正する方法
CakePHPとSimpleTestの連携で以下のようなソースを書いた。 $data = array('username' => 'hogehoge', 'password' => '1234567'); $this->User->create($data); $result = $this->User->validates(); $this->assertFalse($result, 'パスワードが7文字の時はエラーになること'); んで、失敗するテストとして実行したところ、テスト結果のメッセージ(パスワードが7文字・・・)が文字化けするので調べてみたところ、cake\tests\libにあるcake_reporter.phpに問題があることが分かったので今後のためにメモ。 問題となっているのは42行目 function CakeHtmlReporter($character_set =
モックで置き換えの境界線
以前のSymfony勉強会の折にユニットテストとモックの話をさせていただいたのですが、その時に@cakephperさんから次のような意見を頂いていました。 APIを信用して基本Mockでという話、API側の仕様変更を常にウォッチしてないといけないのでフレームワークのアップデートとか大変なんじゃないのかなと思ったんだけど、そこんとこまだ消化できてない twitter - @cakephper まず最初に回答としては「APIが変わるのであれば概ねそのとおり」となります。しかし、これはモックを使うかどうかには関係ありません。ソフトウェアはフレームワークやライブラリ等サードパーティコードの仕様変更に常に影響を受けます。ここで、議論の前提を共有しておく必要があるでしょう。 ユニットテストとファンクショナルテストの使い分け。どちらが書きやすいのか。ユニットテストでテストしたい箇所はどこか。前提として、
PayPal
PayPal Pte. Ltd. はシンガポール法人であり、日本国金融庁に（1）資金移動業者（第二種資金移動業）（関東財務局長第00026号）および（2）前払式支払手段第三者型発行者（関東財務局長第00705号）として登録されています。 お客様により早く安全に情報をお届けするため、お客様が弊社のウェブサイトやサービス、またはアプリケーション等をご利用いただいく際、弊社や弊社が認定したサービスプロバイダがCookieやWebビーコンなどを使用する場合がございます。詳細は こちらをご覧ください。 ペイパルのマネーローンダリング、及びテロ資金供与防止対策に対する取り組み グローバルにサービスを展開する金融機関として、ペイパルはマネーローンダリング、テロ資金供与防止対策を経営上の重要な課題と位置づけており、犯罪収益移転防止法を始めとするマネーローンダリング、テロ資金供与防止対策に関する全ての法令や
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
組織にテストを書く文化を根付かせる戦略と戦術（2019夏版） / Strategy and Tactics of Building Automated Testing Culture into Organization 2019 Summer Edition
開発効率を上げるテスト設計
