メルカリにおけるA/Bテスト標準化への取り組み
2021/7/28, Retty ✕ Mercari Analyst Talk Night! https://mercari.connpass.com/event/218848/
2021/7/28, Retty ✕ Mercari Analyst Talk Night! https://mercari.connpass.com/event/218848/
普段からいくつか趣味で作ったツールやライブラリを npm パッケージとして publish しています。ちょっと工夫していることとして、「できるだけ簡単に npm publish できるようにしておく」というものがあります。npm publish が心理的に、手順的に難しいと、すでに main ブランチに新機能や修正が入っているのに、npm publish されていない、という状況が発生しがちです。新機能や修正をすぐにユーザに送り届けられるよう、npm publish は無思考でできるようになっていると嬉しいです。 その一環として、リリースノート (CHANGELOG) の自動生成というのをやっているので、その紹介をしてみます。本当は 6 月にやっていた Maintainer Month 期間 に間に合わせたかったのですが、とろとろしていたら 7 月になってしまった！ まあ遅れたから公開し
こんにちは、Autify CEOの近澤（@chikathreesix）です。 先日会社の紹介資料を公開しました。大変嬉しいことに多くの反響を頂いているのですが、会社の紹介資料には自動化に賭ける僕の熱い想いは詰め込めきれませんでした。そこで、なぜ我々が今テスト自動化に取り組んでいるのか、なぜテスト自動化がこれからの社会において重要なのか、改めてブログにまとめました。 テストの大半が未だに人手ソフトウェアテストとは、開発したソフトウェアが正しく動作するか検証する作業のことです。ですのでソフトウェアを開発するあらゆる組織において、テストを実施する必要があります。市場は非常に大きく、IT予算の1/3をテストに使っていると言われ、その額は130兆円にも登ります。 この作業ですが、未だにグローバルで見てもおよそ75%の企業が人手に大きく依存しています。人手のテストは当然人件費と時間が多くかかるわけです
#devsumi で「テストを学んでみたい開発者のためのソフトウェアテスト読書マップ」という発表をしてきました。 - ソフトウェアの品質を学びまくる
Developers Summit (デブサミ) 2023で、「テストを学んでみたい開発者のためのソフトウェアテスト読書マップ」という発表*1をしてきました。 event.shoeisha.jp 資料はこちらです。 speakerdeck.com これまで、ソフトウェアテストとかQAの世界でばかり聴講やら発表やらをしておりまして、その外に出る機会があまりありませんでした。 今回、イベント主催者の翔泳社様から発表の打診をいただき、かなり腰が引けていたのですが、「これを機に、もうちょっと外に目を向けよう」という無理やりな動機付けで場を借りることにしました。 といっても結局発表はテストに関することですし、全然外に出ていないのですが・・・まあそれはこれからってことで。 今回は、ソフトウェアQAエンジニアの有志が一気呵成に作り上げた『ソフトウェアテスト読書マップ』を借りた発表であり、みなさんの成果を
スタートアップにクリーンアーキテクチャを適用したが、技術的負債が塵積った件 〜開発合宿で技術的負債を粉砕します〜 - ANDPAD Tech Blog
こんにちは。こんばんは。おはようございます。 アンドパッドで現在はバックエンドの方のエンジニアをやっている原田です。 アンドパッドには2021年6月にJOINしまして、現在までANDPADボードの開発に携わっています。 ANDPAD施工管理が比較的長期間の工事をターゲットにしているのに対して ANDPADボードは1日〜数日の間に短期間の工事や施工を行う際のスケジュール管理を行えるサービスです。 andpad.jp 今回は入社3ヶ月目というきりの良いタイミングで今まで行ってきたことを振り返りつつ、直近行った技術的負債を軽減するための「開発合宿」について書いていきます。 一応最初に書いておきますが、リファクタリングに関するチートスキルはないのでバーンとやってドーンと解決みたいなド派手な解決ではなく地道な改修作業をちまちま行いましたという内容です。 入社してからやってきたこと ANDPADボード
品質やテストといった活動が「本質的にアジャイルになって変わらなければならない」といった問題を定義し、その解決手段を提案する「今、全エンジニアに求められる『アジャイル開発での品質視点の変化』」。ここで株式会社デジタルハーツホールディングスの高橋氏が登壇。最後に、あらためて参加者からの質問に回答します。前回はこちらから。 どうすればうまくリファクタリングができるか 高橋寿一氏（以下、高橋）：じゃあここでもう1回Q&Aタイムを取ります。 高木陽平氏（以下、高木）：ありがとうございます。今Q&Aにまだ質問が上がっていないみたいなので、ちょっと私から質問します。リファクタリングをしなければいけないところって、逆に手をつけられないようなけっこう複雑怪奇な部分だと思うんです。そこらへんはどうすればうまくリファクタリングができるんでしょうっていう（笑）。 高橋：まず、日本人がすごくリファクタリングが嫌いな
失敗から学ぶAPIファースト / API first learning from failure
Presentation Slides for ServerlessDays Tokyo 2023 (
Androidの父ことAndy Rubin氏は、Twitter上にて、見たこともないほど縦長の端末を披露しました。 背面は角度によって宝石にように色を変える光沢素材が採用されています。 GEM Colorshift material pic.twitter.com/QJStoiDleH — Andy Rubin (@Arubin) October 8, 2019 筐体に合わせ、とんでもなく縦長のディスプレイを搭載。UIも最適化されています。縦長に合わせたアプリケーションランチャーと、地図アプリを確認できます。 Andy Rubin氏はGoogle退社後に設立した企業Essential社で、いち早くノッチを採用したEssential Phoneをリリースしていました。最近のXperiaも21:9で攻めていますが、それをも上回るほど縦長ですね。 縦長に合いそうなUIといえば、縦方向にスクロール
近年のソフトウェア業界では、テスト関連活動を担うエンジニアを「QAエンジニア」と呼ぶようになっています。ただQA（品質保証）という言葉は、旧来から二つの定義が共存しているほか、業界内の通例で更に別の意味付けが行われた結果、定義が曖昧になり誤解を生みがちな状態となっています。 そこで今回は、日本語圏で、QA（品質保証）の言葉がどのように定義されているか、整理して解説します（結論からいうと三流派あります） 国際標準規格での定義：品質マネジメントシステムの実証 IEEEやISOといった国際的な標準規格、およびそれに準拠した知識体系や標準では、古くから体系立てて品質マネジメント、品質保証、品質管理の定義を行っています。 有力な文献として、品質マネジメントの標準規格である、ISO 9000：2015の定義を紹介します。 まずISO 9000では、品質保証の前提として品質マネジメントという用語を使って
DBMS に依存するロジックのテストを書く時、主に2つの手法があると思います。 Repository 層などを mock する Service 層のテストをする時は、その下位の Repository 層を mock して、DBMS に依存しない形にしてからテストする レイヤードなアプリケーションで適用できる手法 テスト実行時も DBMS を裏で動かして、それを使う 本番と同じスキーマを持つ DBMS に対して、実際に insert したり select してテストする DBMS は docker-compose upとかで事前に立ち上げておく 双方にそれぞれ良さがあって、プロダクトによってどっちでやるか変わってくると思います。 この記事では 2 の手法を Prisma でどうやるかについて紹介します。 前提 実際のテストコードの例 テストヘルパーを作る 別解: ヘルパーを自動生成する je
テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について - Qiita
皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか？少なくとも私は今までテストカバレッジ100%を追求していました。「C0/C1カバレッジ100%」がユニットテストの完了条件として含まれているプロジェクトも多いかと思います。 本稿では、「カバレッジが高ければ、ソースコードの品質が高い」という命題がなぜ誤っているのかを論理的に証明し、カバレッジを計測する本当の目的、そして推奨されるカバレッジの目標値について紹介したいと思います。 「カバレッジが高ければ、ソースコードの品質が高い」はなぜ間違っているのか？ カバレッジを計測する本当の目的 バグを潜在させてしまう恐怖のテストケース・アンチパターン カバレッジの目標値は100%にするべきではない カバレッジの目標値は何%にするべきなのか？ （テストカバレッジの種類については『ホワイトボックステストにおけるカバレ
質とスピード（AWS Dev Day 2023 Tokyo 特別編、質疑応答用資料付き） / Quality and Speed AWS Dev Day 2023 Tokyo Edition
AWS Dev Day 2023 Tokyo GS-1-2 | 6月 22 日（木）10:55 - 11:45
高品質と高スピードを両立させるテストアプローチ/Test Approach that Improves Quality and Agility Together
PHPカンファレンス小田原2024での発表資料です https://fortee.jp/phpconodawara-2024/proposal/4d39c7ef-058c-4648-b1d7-5510497e0d81
#yamagoya2020 で 2020/11/25 に登壇させていただいたセッションの資料です。
米国防総省、オープンソースをプロプライエタリより優先的に採用する調達方針を明らかに。同省CIOが書面で通知 米国防総省は「Software Development and Open Source Software 」（ソフトウェアの開発とオープンソース）と題する同省CIO John B. Sherman氏の1月24日付けの書面を公開し、プロプライエタリな製品を購入する前に、既存の政府ソリューションやオープンソースソフトウェアの採用を優先する方針を示しました。 この書面は、セキュアなオープンソースソフトウェアや商用ソリューションの採用を増やすことを同省に指示した2018年7月発表のサイバー戦略の下で、どのようにオープンソースソフトウェアを位置づけるかを説明するものです。 書面の本文で、オープンソースを採用する上で2つの懸念を示した上で、付録のガイドラインで具体的な方針を明らかにしています。
概要 ※この記事は弊ブログ記事(はてな)、Kubernetesの負荷試験で絶対に担保したい13のチェックリストと同内容です ここ最近、Kubernetesクラスタを本番運用するにあたって負荷試験を行ってきました。 Kubernetesクラスタに乗せるアプリケーションの負荷試験は、通常の負荷試験でよく用いられる観点に加えて、クラスタ特有の観点も確認していく必要があります。 適切にクラスタやPodが設定されていない場合、意図しないダウンタイムが発生したり、想定する性能を出すことができません。 そこで私が設計した観点を、汎用的に様々なPJでも応用できるよう整理しました。 一定の負荷、スパイク的な負荷をかけつつ、主に下記の観点を重点的に記載します。 Podの性能 Podのスケーラビリティ クラスタのスケーラビリティ システムとしての可用性 本記事ではこれらの観点のチェックリスト的に使えるものとして
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
どうも、sakitoです。 今回は私の推しフロントエンドディレクトリ構成と気をつけたいポイントを紹介します。ちぇけら！ 2023年5月29日 追記 この記事を読みにきていただきありがとうございます。 私が記事を書いた時期はまだNext.jsのApp Routerが発表されたばかりで、App Routerを使用したディレクトリ構成の考慮はされていません。 先日、App Routerがリリースされ、Next.jsのドキュメントにApp Routerのディレクトリ構成について記事が出ているので、Next.jsを使用されている場合は、まず参照することをオススメします。 はじめに 今回、私の紹介する推し構成は、機能単位で設計するパターンです。 Reactのディレクトリ構成のベストプラクティスを集めたBulletproof Reactで紹介されているパターンにかなり似ています。さらに詳細なプロダクト構
ソフトウェアテスト読書マップ
ABCEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAF
学習者が、「どの資料が、どんなレベルで、どのトピックについて言及しているか」をざっくり把握できること。
Googleに存在するコードを読みやすく保守しやすい形に保つ取り組みを行うグループ「Code Health」が、「DRYを早まって適用しないこと」と題した記事を公開しました。 Google Testing Blog: Don't DRY Your Code Prematurely https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html DRYは「Don't Repeat Yourself」の略称で、コードを重複させないことを重視する考え方です。重複するコードが存在していると、特定の機能を変更しようとした時に同じ機能を持つ部分を全て探して同時に変更する必要があり、見落としやミスが発生する危険性が高まります。一方、コードの重複を防げていれば一カ所だけを変更すればOKというわけ。 一見DRYを厳しく適用
Nuxt Scriptsって何ができるの？ Nuxt4メインセッションに添えて@Vue.js v-tokyo Meetup #21
Products Docker DesktopContainerize your applicationsDocker HubDiscover and share container imagesDocker ScoutSimplify the software supply chainDocker Build Cloud Speed up your image buildsTestcontainers Desktop Local testing with real dependenciesTestcontainers Cloud Test without limits in the cloud See our product roadmapMORE resources for developers
Platform チームの@deeeeeeeetです． Platform チームは2年前にMercariがMicroservicesの移行を始めたときに一緒に立ち上げられたチームです．Platform チームはMicroservicesを動かすための基盤や開発や運用のためのツールセットなど提供しています．立ち上げ時は自分を含めて2-3人で始まったチームですが2年が経ち10人を超えるチームにまで成長しました． チームのメンバーが増えるほど1チームとして動くには限界がきており，またMicroservices化が進めば進むほどチームの負う責任範囲も広くなりCognitive load (認知負荷) も高くなっていました．これらの課題を解決するために組織変更を行い，Platform チームを複数の専門性に特化したチームに分割しました． 本記事ではチームのデザイン，チームが分離しても独立性を保ちつつ
プログラマ、テスト駆動開発者 和田卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ power-assert-js 作者。 講演や執筆などを通じ、日本におけるテスト駆動開発のエバンジェリストとして知られる和田卓人さん。 TDDとは何かを改めて言語化してもらった前回の記事では、「テストを書かずに進むのが合理的といえるときはある。でも、後からテストを書くのって難しいしつらい」とのお話がありました。 テストが書かれないまま
[Developers Summit 2023] ソフトウェアテスト新時代の幕開け: 機械学習とデータサイエンスで実現するテスト運用の高度化
Developers Summit 2023 の公募セッションで発表した資料です。https://event.shoeisha.jp/devsumi/20230209/session/4142/
![[Developers Summit 2023] ソフトウェアテスト新時代の幕開け: 機械学習とデータサイエンスで実現するテスト運用の高度化](https://cdn-ak-scissors.b.st-hatena.com/image/square/0efe72a56b9d43a41e40530a646876ce37b6a9d5/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F2037a09e17cf4398ab0006d4fcfea1f9%2Fslide_0.jpg%3F24408296)
こんにちは、テストが好きなsilverbirderと申します。Webフロントエンドのテストは実施していますか？ユニットテストやビジュアルリグレッションテストは広く知られていると思います。しかし、パフォーマンステストのためのテストコードはありますか？また、カオスエンジニアリングテストやアクセシビリティテストはありますか？ 今回、私はWebフロントエンドにおける網羅的なテストパターンを調査し、その結果をここで紹介したいと思います。これらを理解することで、読者の皆さんが適切なテスト戦略を策定する際の参考になれば幸いです。 前提 今回、テスト対象として取り上げる題材は、TodoMVCというTODOアプリです。フレームワークとしてReactを使用しますが、紹介するテストパターンはフレームワークに依存しないものです。ただし、使用するライブラリはReactに関連しているため、その点についてはご了承くださ
【翻訳記事】BDDの考案者が執筆した記事「テストについて話し合わなくてはならない」を翻訳しました！ - ブロッコリーのブログ
目次 目次 はじめに（本記事の見どころなど） テストについて話し合わなくてはならない テストの目的 「うまくいかないかもしれないものは何ですか？」 なぜテストをするのですか？ この場合に限り…… テスト駆動開発 〜テストについて語る前に説明が必要です〜 テストについて話しましょう なぜすべてのテストを自動化しないの？ テストカバレッジは有用な指標ですか？ 「テストをシフトレフトする」とはどういう意味ですか？ いつ、どこでテストすべきですか？ 十分なテストとはどれくらいですか？ おわりに はじめに（本記事の見どころなど） 今回は著者本人の許可をもらった上で、「テストについて話し合わなくてはならない」（原題は「We need to talk about testing」）を翻訳したので紹介します。 dannorth.net 本記事はDaniel Terhorst-North(Dan North
基盤チームの右京です。 昨今はフロントエンドのアプリケーションもリッチになり、ブラウザ上で実行されるコードが行うことの範囲も増えてきました。一方で多くのことを実装できてしまうのはリスクでもあり、BASE でも問題となることがあります。 その中でも「開発環境の URL」や「デバッグ機能の存在」ような環境毎に異なる情報は、特に意図せずに漏れやすいものだと考えています。これらはコードを記述する際に、実装方法を知識として知っていればその多くが回避可能です。この記事ではその実装例を解説しています。 コードから漏れる情報 例えば、次のようなコードがあるとします。 function debug() { // 開発環境の host であればデバッグ機能を有効にする return location.host === 'dev.example.com'; } なんの変哲もないようなコードに見えますが、ブラウザ
What’s Hurl? Hurl is a command line tool that runs HTTP requests defined in a simple plain text format. It can chain requests, capture values and evaluate queries on headers and body response. Hurl is very versatile: it can be used for both fetching data and testing HTTP sessions. Hurl makes it easy to work with HTML content, REST / SOAP / GraphQL APIs, or any other XML / JSON based APIs. # Get ho
StackScript、k8s、Terraformを使って、Linodeで負荷試験環境を自動で構築する方法について、アカマイ・テクノロジーズの岡本英輝氏と佐藤裕行氏が、実際のデモを交えて紹介しました。後半はLinodeを使った負荷試験のデモとQ&Aについて。前半はこちら。 Linodeのメリットが得られやすいユースケースとは？ 佐藤裕行氏（以下、佐藤）：後半は、Linodeのユースケースについて、少し岡本さんと話を進めていきたいと思うんですけども。今回はアプリケーションの負荷試験にフォーカスして、デモなども見せていきます。 その前に、負荷試験以外のサービスでいうと、こういうのに向いているとか、こういうのに向いてそうなところって、なにか感覚として持ってたりしますか？ 岡本英輝氏（以下、岡本）：前半に続いて、ちょっと転送量コストの話ばっかりになってしまうんですけど、やはりアウトバウンド転送量を
過度なDRYは読みやすさの敵！？「リーダブルテストコード」という発表をしました #vstat - give IT a try
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
ブラウザ自動操作技術の深層へ、直接触れて学ぶ WebDriver と Chrome DevTools Protocol
ウェブアプリケーションの開発においてE2Eテストの自動化は身近なトピックです。SeleniumやPuppetter、PlaywrightやAppiumなどがブラウザ・ネイティブアプリの自動操作のOSSとしてよく挙げられます。しかし、それらの裏側はご存知でしょうか？ 本トークではこれらのツールの背後…
皆様フロントエンドのテストを書いていらっしゃいますでしょうか？ フロントエンドのテストを書くときには API コールする処理を全てモックする必要があります。外部の API をコールする処理をテストに含めると API サーバーが落ちているなどの外部の要因によってテストが失敗してしまう可能性がありますし、テストを実行するたびに実際に API をコールしてしまうとサーバーに負荷がかかってしまうなど外部に対しても悪影響を与えてしまいます。 さて、従来のモックする手段としては Jest のモックを利用して axios や fetch などのモジュールをモック化する手法がよく使われていたかと思います。 最近のテスト手法として API コールをモックする際に Jest ではなく Mock Service Worker (以下 msw ）を使用する手法が注目されています。実施にどのように使用されているのか
実行環境依存のコードに対してテストを書く考え方
社内用の啓発記事ですが、閉じる理由がないのでここに投げます。 ブラウザにべったりなコードを書いてると、ブラウザや node.js 固有の環境をインラインで記述してしまうことが多々あると思います。 あえてダメダメなブラウザ向けのエントリポイントの例を書きます。 // main.ts let id = localStorage.get('id'); if (!id) { id = `${navigator.userAgent}-${Math.random()}`; localStorage.set('id', id); fetch('/auth', { method: 'POST', credentials: 'include', body: JSON.stringify({ id, at: Date.now(), }), headers: {'Content-Type': 'applicat
テストでのデータベース単位の捉えかた - 日々常々
データベース（に限らずあらゆる永続化リソース）を使用するテストをいかにして行うかはいつだって悩みの種です。この悩みは「どうやったらデータベースを使用するテストを行えるかわからない」ではなく「なんとかやってるけど、不満のようなものがある」というものになるかと思います。 やりかたはたくさんあるのですが、その優劣は条件なしに比較する意味がないくらい、条件に依存します。どんな選択肢も「この条件なら最適」と言えてしまうだけに、広いコンテキストで「こうするのがベスト」とも言いづらいのです。 前提 xUnit Test Patterns を下敷きにします。 ユニットテストでの話です。他でもある程度通じます。 具象イメージはSpringBootを使用するWebアプリケーションです。そこまでべったりな内容ではありませんが、背景にあるとご理解ください。他でもそれなりに通じます。 データベースを使用するテストで
実践 9 つのメモリリークどう見つける？/ How to detect 9 types of memory leaks?
iOS Test Online 2022/10/28 https://testonline.connpass.com/event/261910/
freeeが書店経営に参入
freeeは3月9日、書店経営を始めると発表した。新子会社として透明書店（東京都台東区）を設立。4月下旬をめどに、台東区蔵前に書店を開く。 「freee自らがスモールビジネスの経営をすること、そしてfreeeの社員が実際にバックオフィス業務を経験することで、スモールビジネスの実情とそれに取り組むユーザーを理解する」（freee）。月々の売り上げや経営状況、従業員数や経費などは全て公式noteで公開するという。 書店は新技術を試す場としても活用する。すでに提供しているfreeeのサービスに加え、未発表のサービスやChatGPTといった新技術をテスト。デジタル化の余地が大きい書店経営への影響を確認するとしている。 関連記事 マネーフォワード、PCを販売 マネーフォワードが、法人向けSaaSをまとめたオンラインストアで、PCなどハードウェアの販売を始めた。IT担当者がいない中小企業など、ハードウ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リリースノート自動生成テクニック - mizdra's blog
なぜ今ソフトウェアテスト自動化に賭けるのか | chikathreesix
「まともに単体テストを書ける人は実はすごく少ない」 市場バグを発生させない“単体テストで対処する”という考え方
Androidの父、とんでもない縦長端末を披露！ - すまほん!!
品質保証（QA）とは。定義の三大流派と定義揺れの弊害 - 千里霧中
Prisma で本物のDBMSを使って自動テストを書く - mizdra's blog
テスト設計チュートリアル/Test Design Tutorial
単体テストを書かない技術 #phpcon_odawara
FastlyとTypeScriptで実現するカナリアリリース / yamagoya2020
米国防総省、オープンソースをプロプライエタリより優先的に採用する調達方針を明らかに。同省CIOが書面で通知
Kubernetesの負荷試験で絶対に担保したい13のチェックリスト - Qiita
BudouX: 読みやすい改行のための軽量な分かち書き器
私の推しフロントエンドディレクトリ構成と気をつけたいポイント
ソフトウェアテスト読書マップ - Google ドライブ
「コードに早まってDRY原則を適用しないこと」とGoogleが呼びかけ
サービスの持続的な成長と技術負債について
Introduction to heredocs in Dockerfiles | Docker
どのようにPlatformチームの組織変更をしたか | メルカリエンジニアリング
t-wada氏に聞く、テストを書き始めるための「はじめの一歩」 - レバテックラボ（レバテックLAB）
Webフロントエンドにおける網羅的テストパターンガイド
フロントエンドのコードからの情報漏洩を防ぐための工夫 - BASEプロダクトチームブログ
Hurl - Run and Test HTTP Requests
“わずか10分”で「負荷試験環境」の構築が可能に クイックにチェックできる状況をサクッと作れる、Linode活用法
Poku
フロントエンドのテストのモックには msw を使うのが最近の流行りらしい