jestでDBありのテストを高速化する
課題link お手伝いしているシステムでNestJSを採用しているバックエンドのテストが遅いという課題があったので対処した。 前提link フレームワークDBテストランナーその他 テストの総数は700弱。 最終結果link 最終的には2段階の改修を経てローカルのテストが3倍速程度高速化した。 # before Test Suites: 145 passed, 145 total Tests: 2 skipped, 681 passed, 683 total Snapshots: 0 total Time: 925.063 s Ran all test suites. Done in 926.48s. # ts-jestを@swc/jestに置き換えた Test Suites: 145 passed, 145 total Tests: 2 skipped, 681 passed, 683 t
yamlでテストシナリオを書いてそのまま実行までできるAPIテストツールの新星 “runn” を試してみた | DevelopersIO
yamlでテストシナリオを書いたらそのまま実行できる……そんな夢のようなシナリオテストツール"runn"の紹介とやってみた記録です これまでのシナリオテストツールに対する課題感 シナリオテストツールといえば、 Cucumber や Gauge といったツールが有名です。 ですが、これらのツールは「シナリオファイル」とは別に、シナリオを実行するためのコードも書かないといけません。しかも、そのコードではAPIを呼び出す処理を特定のプログラミング言語を使って書かなければなりません。その中には、HTTP Clientを実際に操作するような処理も含まれます。 私は「シナリオテストがしたい」のであって、「シナリオに沿ってAPI呼び出しを行う処理を書きたい」のではありません。こういった課題感を、ここ数年ずっと抱えてきました。 そんなとき、ついに見つけたツールが "runn" でした。 APIのシナリオテ
iOSDC Japan 2023 にて登壇した内容となります。 https://fortee.jp/iosdc-japan-2023/proposal/eb9d4449-4ff8-421d-9ffb-691179245d14 登壇のアーカイブ https://www.youtube.com/watch?v=9GbG13-jMVM
AI時代にこそTDDだと思う話
GitHub Copilot、みなさん使ってますか？すでに多くの方が利用しており、「ないと困る」という方から「提案の質に問題がある」「まだまだ使えない」という方まで、様々な意見を聞きます。 筆者はGitHub Copilotに対して非常にポイティブな立場です。GitHub Copilotは使い方次第で開発速度を格段に向上させることを身をもって体験しており、これからの時代においてはGitHub CopilotなどのAIツールを使いこなせるかどうかで、個人の開発速度に非常に大きな差が出ると考えています。 重要なのは使い方次第と言う点です。前述のように様々な感想が溢れているのはAIツールの習熟度が大きく影響しているようにも感じます。AIツールは静的解析同様、利用者側の手腕が大きく問われるツールであると筆者は感じています。コマンドプロンプトエンジニアリングという言葉もあるように、AIツールを使いこ
「テストコードにはテストの意図を込めよう」の発表報告＆補足説明＆質問回答 #vstat - ブロッコリーのブログ
先日、「リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～」というイベントで登壇してきました。 veriserve-event.connpass.com 今回は発表内容に対する補足と、発表に対していただいた質問に回答します。気になるところだけでも読んでもらえればと思います。 目次 目次 発表内容 発表に対する補足 【補足1】都道府県のテストについて 【補足2】Parameterized Testsへの利用について いただいた質問の回答 【質問1】リーダブルなテストコードの勉強方法はありますか？ 【質問2】テストコードのメンテナンスをするにあたってのリファクタリングの頻度はどれくらいか？ 【質問3】レビューをする際、機能自体のレビューにかけた時間に対してテストのレビューにかける時間はどのくらいの割合で行っていますか? 【質問4】
こんにちは。フロントエンドエキスパートチームの穴井（@pirosikick）です。福岡在住で、普段は福岡のweworkで働いています。他のメンバーは皆、東京に居てリモートで仕事をしていますが、モブでわいわい開発していますし、weworkが快適すぎて、毎日楽しいです！ フロントエンドエキスパートチームでは、サイボウズの各プロダクトが抱えるWebフロントエンドの課題を解決するのが仕事の一つです。 blog.cybozu.io 最近の取り組みとして、Puppeteerで不要なCSSを消した事例を紹介します。 このブログは、6/19に福岡で開催した「Google I/O '19のWebをまとめる会」で登壇したときの内容を詳細に説明しつつ、アップデートした部分もあるので、発表見たぞ、スライド見たぞという方も見ていただけますと幸いです。 speakerdeck.com きっかけ とあるプロダクトのCS
private 関数にもテストを書きたいとき
「private 関数にはテストを書かない」というのが多数派だと思う。だが昨日、仕事で In-source testing を書いていたらふと private 関数にテストを書きたくなった。そこで、In-source testingができる環境下でもprivate 関数にテストを書くべきかを X で聞いてみたら何か盛り上がっていた。 (In-source Testing: https://vitest.dev/guide/in-source.html) 反応を見る限り、やはり「private 関数にはテストを書かない」の方が主流だった。Kent Beck先生の http://shoulditestprivatemethods.com を紹介するツイートにもそういった反応が寄せられていた。（ぶんぶんさん、教えてくれてありがとうございます。） （このサイト面白すぎますよね・・・） 自分の立場を
should i test private methods?
System tests have failed
When we introduced a default setup for system tests in Rails 5.1 back in 2016, I had high hopes. In theory, system tests, which drive a headless browser through your actual interface, offer greater confidence that the entire machine is working as it ought. And because it runs in a black-box fashion, it should be more resilient to implementation changes. But I'm sad to report that I have not found
RustでAPIを開発してみたら結構辛かった話
はじめに 皆様こんにちは、株式会社プラハのAwataです。 今日は、以前書いたリーダーの振り返り記事で軽く触れていた、RustでのAPI開発についての記事を書いていこうと思います。 結論RustでWebは辛い！という話なんですが、約5か月くらいRustでWeb開発をしたので、今後の参考になるようなことを書いていこうと思います。 ぜひ最後までお付き合いください。 TL;DR RustでWeb開発はまだ早いかもしれない。 RustでDDDはやりやすい。ただしDIがやりにくい場合があるので、そこは要注意。 Rustはモジュールの仕組みが協力なので、モジュラモノリスはやりやすい。 サンプルリポジトリはこちら Rustはやっぱり難しいけど人気の理由も少し分かった気がする そもそもなぜRustでやってみようとなったのか 前例が少ない中、どうしてRustで開発しようと思ったのか気になる方も多いと思います
Agile Testingを夢見たテスト自動化 〜ATDDへの挑戦から始まる 1年間の試行錯誤〜 / dreaming agile testing at basebank
「CIのためのテスト自動化」というテーマで第17回QUESに招待いただいた際の資料です。 - Agileチームにおけるテスト自動化の試行錯誤から得られたしくじり - Agile Testingの概要とその一つの取組みとしてのATDDの実践をテスト自動化目線で - システムレベルの自動E2Eテストの作成・維持に焦点を当てる
Postman 入門
今回の記事は、2023年8月29日に開催されるPostman Meetup Fukuokaの登壇に向けて、Postmanへの感謝を伝えるために執筆した記事である。 今回の記事は、これからPostmanを実務で導入するプログラマーを対象に基本的な使い方を解説した記事になる。Postmanの専門的な使い方を知りたいならPostman Learning Centerを確認してほしい。本記事はあくまで二次情報に過ぎないので、より正確な情報を求めるならそちらを参照すること。 今回の記事では、API設計・開発で重宝するサービス「Postman」の使い方を解説する。 対象者 これからPostmanを学ぶひと 実務でPostmanを触っているひと Postmanに興味があるひと タイトルでなんとなく気になったひと Postmanとは PostmanはWeb API(以下「API」)の設計・開発、テストをサ
t_wadaさんの「レガシーコード改善ワークショップ」体験記🦁 - コドモン Product Team Blog
こんにちは！コドモン開発部の加藤です。 すっかり暑くなってきましたね。我が家では猫が換毛期を迎えて、家中毛だらけになりながらも日々なんとか暑さを乗り切っています。 最近コドモンでt_wadaさんにレガシーコード改善ワークショップを行っていただきました。 今回はそのワークショップの様子についてレポートしていきます！ レガシーコード改善ワークショップの概要 t_wadaさんの紹介 ワークショップの目的と内容 目的 1.午前の部 2.午後の部 ワークショップ中のハイライト 午前の部 活発な実況チャンネル🗣️ テストを書いただけでは設計はよくならない、を実感する😬 質問コーナーではE2E肥大化の課題に注目が集まる👀 午後の部 最初のテスト作成をライブコーディングで学ぶ💪 実践を始めると意外と手が動かない……🥺 人が1on1を受けている姿をみられるの貴重👏 まとめ レガシーコード改善ワー
PyCon JP 2020での発表スライドです。 --------------------------- (2020/08/30) 誤字を修正しました。 場所: p15 誤: assert_array_close() 正: assert_allclose() --------------------------- (2020/08/31) 誤字を修正しました。pandas.util.testingは動作しますが、pandas1.0以降ではdeprecatedになっており代替としてpandas.testingを使うことが推奨されています。 場所: p17 誤: pandas.util.testing 正: pandas.testing なお、p18のサンプルコードは元々pandas.testingで説明していたため変更はありません。 --------------------------- ト
チーム開発を加速するテストの育て方
テストを書いてないというチームには色々理由があると思いますが、「何をテストすべきかわからない」「書き方がわからない」「どのくらいメリットがあるかわからない」という意見は多いのではないでしょうか？テスティングフレームワークの選定や使い方を学ぶのは重要ですが、それ以上にテストの目的や戦略を学ぶことが重要です。チーム開発においてテストを活かすのは相応の知識とスキルが必要になりますが、活かせればテストは開発スピードを維持・促進する飛び道具になり得ます。 本稿は筆者が取り組んで実際に高いチーム満足度と速度を得られた、テスト戦略についてまとめたものです。
tl;dr git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。 これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。 本題 よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を本番に入れたい場合には以下のようなフローを踏むことになるでしょう。 featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ developブランチにfeatureブランチにマージしてテストが通るのを待つ mainブランチにdevelopブランチをマージしてテストが通ったらdeployする さて、この時、他の作業が混ざらない限りにおいては1,2,
大企業向けビジネスの信頼を支えるために半年かけてゼロからユニットテストを充実させたら、開発者も幸せになった 工夫5選 - MonotaRO Tech Blog
初めまして、購買ソリューショングループ 運用・機能改善チームの稗田です。当社では自社で運営しているECサイト(モノタロウドットコム)から直接商品をご購入いただく他に、他社の購買システムと連携して商品をご購入いただくシステム(大企業連携システム)があります。こちらの大企業連携システムには多くのバッチ処理があるのですが、これまで自動テストがありませんでした。今回はバッチ処理の障害をきっかけに短期間でユニットテストを充実させるためにした工夫や学んだことをお話しします。 ユニットテストを作らなければいけないと思ったきっかけ 障害発生 担当システムやチームの状況 チームの1人として感じたこと お客様やステークホルダーの信頼を取り戻すために ユニットテストを短期間で作成するためにやった工夫 工夫1: 外部協力会社の力を借りる 工夫2: 課題や目的、ルールをドキュメントで共有する 工夫3: リファレンス
2023年5月17日から5月19日にかけて開催された Qiita Conference 2023 にて、弊社の Senior Technical Support Engineer である末村 拓也が『リファクタリングが先か、テストが先か – E2E自動テストの理想と現実』というタイトルで講演を行いました。本記事はこのセッションを元に、ブログ向けに若干アレンジを加えたものとなります。 概略 この記事では、以下のような内容について説明します。 自動テストコードはアプリケーション本体のコードと 依存関係 を作る 一般的に、 不要な依存関係 を排除するのが良い設計と言える 一方で、E2Eテストは GUIに対して強い依存関係 を作る テストの準備などで GUIとの不要な依存関係 を作らないようにするのが重要 不要な依存関係を減らすために、テストレベル を一つ落とす（ユーザーストーリーE2E） 低いテ
TypeScriptでテストコードを徹底的に型推論する / TypeScript Meetup 4
2020年6月16日 TypeScript Meetup #4 にて発表した資料です。
新しい UI テストの手法を提供するテストライブラリ SafeTest 2024.02.25 SafeTest は Playwright と Jest/Vitest を組み合わせた UI テストライブラリです。特定のライブラリに依存せず、React, Vue, Angular, Svelte などのフレームワークに対応しています。SafeTest は単体テストと Playwright を使った E2E テストの手法を組み合わせることで、それぞれの手法が抱える欠点を補うことを目指しています。 SafeTest は Playwright と Jest/Vitest を組み合わせた UI テストライブラリです。特定のライブラリに依存せず、React, Vue, Angular, Svelte などのフレームワークに対応しています。 従来のフロントエンドのテストの手法は Testing Libra
フロントエンドテストにおける知見の宝庫を発見！「javascript-testing-best-practices」
はじめに JavaScriptにおけるテストのベストプラクティスをまとめた「javascript-testing-best-practices」というGitHubレポジトリが大変勉強になったため、特に参考になった内容をまとめて共有したいと思います。 （補足）本レポジトリにはfrontendのみならずbackendのテストに関する情報もありますが、今回はfrontendに焦点を当てて共有します。そのため扱うSectionは以下の4つです。 Section 0: The Golden Rule Section 1: The Test Anatomy Section 3: Frontend Section 4: Measuring Tests Effectiveness 想定読者 フロントエンドの実装はできるが、テスト経験はない方 テストに対して解像度が低い方 これからテストを学びたいと思ってい
[Rust] モジュールのベストプラクティス
Rust のモジュールシステムは私の知る中でもトップクラスによくできた仕組みだと思います。特にリファクタリングによってモジュールを再構成するときのやりやすさは他の言語では経験できないものです。例えばそれなりの規模の Python プロジェクトを回帰バグを導入せずにモジュール構造のリファクタリングするのは不可能に近いですが、 Rust ではそのような不安を覚えたためしがありません。 Rust のモジュールシステムがどういうものかは、 The book にも書かれていますし、すでに大量のガイドが書かれていると思います。しかし、どのように使うべきかについては意外なほど情報が少なく感じます。 ベストプラクティスというのもおこがましいですが、数年使ってきて Rust のモジュールシステムを使う上でスムーズに感じる方法をまとめておきたいと思います。 Rust のモジュールシステム 本稿の主題はモジュー
![[Rust] モジュールのベストプラクティス](https://cdn-ak-scissors.b.st-hatena.com/image/square/891eeb61cb537942f816adc8c8b2ea1079e47749/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--9-GnInIk--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BRust%25255D%252520%2525E3%252583%2525A2%2525E3%252582%2525B8%2525E3%252583%2525A5%2525E3%252583%2525BC%2525E3%252583%2525AB%2525E3%252581%2525AE%2525E3%252583%252599%2525E3%252582%2525B9%2525E3%252583%252588%2525E3%252583%252597%2525E3%252583%2525A9%2525E3%252582%2525AF%2525E3%252583%252586%2525E3%252582%2525A3%2525E3%252582%2525B9%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Amsakuta%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EvQUFUWEFKeG5tZ0ZYQlJsZjJpZVh1QWlwOG9LaFdpT2FSczg2dXRzWlcwN3o9czk2LWM%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
こんにちは。カミナシにて業務委託としてフロントエンドを担当している田村(@junkboy0315)です。皆さんはフロントエンドのテスト、どのように取り組んでいますか？フロントのテストはなかなか難しいですよね。 バックエンドのテストには、「入力、出力、永続化されたデータ」の3つを検証するという基本セオリーがあります。しかし、フロントエンドのテストは、その粒度や手法が多様で、とっつきにくいと感じる方も多いのではないでしょうか。 カミナシでもフロントエンドのテストは以前は十分とは言えない状態でしたが、これまで継続的に改善を重ねてきました。今回は、その変遷についてお話ししようと思います。 夜明け前 カミナシのコードベースでは、元々ユニットテストがある程度整備されていました。これらは主に複雑な計算処理を行い結果を返す関数などに対して実施されていました。 しかし、画面全体の機能を網羅する包括的なテスト
dockertest のススメ
概要 dockertest は go でテストを書く際に docker 経由で指定したコンテナを起動してくれてテストが終わったらコンテナを削除してくれる便利ライブラリです。 モチベーション 時雨堂では TimescaleDB という PostgreSQL に TSDB 拡張を追加した少し変わった RDBMS を利用しています。 TimescaleDB 専用の関数があったりするため、モックなどを使わずにテストを書くのが現実的です。 dockertest ory/dockertest: Write better integration tests! Dockertest helps you boot up ephermal docker images for your Go tests with minimal work. 基本的には dockertest の README に書いてある内容を
【翻訳記事】テストに対する考え方「Testing Manifesto」 - ブロッコリーのブログ
はじめに（Testing Manifestoを紹介するに至った背景） 既にこのブログでお伝えしたように、先日『Agile Testing Condensed』の日本語翻訳本を出版しました。 この書籍の中で、テストマニフェスト（Testing Manifesto）が紹介されています。 アジャイルソフトウェア開発宣言（Agile Manifesto）を元ネタにして作ったものだと思います。 この考え方は書籍を購入していない人にもぜひ知ってほしいと感じているので、この記事でも紹介することにしました。なお、記事に載せることについては、この画像の作者であるKarenとSamにメールを送り許諾を得た上で掲載しています。*1 テストマニフェスト 翻訳した画像はこちらです。*2 オリジナルの画像等はこちらにあります。 www.growingagile.co.za また、画像だけでなく文章も残しておきます。
対象 業務レベルでサーバーサイドでJestを書いたことはないけれど、新プロジェクトでは書くことになったみたいな方を想定して記述しています。 Jestについては中々ベストプラクティスが集まりにくいので、経験的にこう書くと「きれいに」・「早く」・「正確に」書けるよというTipsを集めてみました。もし、よろしければお読みください。 前提 TypeScript Node.js Jest DBアクセスありの状態を想定しています 1. it文内では、必ず1回は、expectをつかって検証をする JestのPRをレビューしてるとたまに見受けるのですが、expectを使ってないケースがあります。 // NG it('userを正常に、作成できること', async() => { await createUser({ name: 'Mike' }); }); // OK it('pdfが正常に削除できること
はじめに JavaScriptのモックライブラリでは、 sinon などが有名であるが、テスティングフレームワークに Jest を使ってるならば Jest組み込みのモックライブラリで済ませたほうが学習コスト少なくて済むだろうと思える。 しかし、 sinon の感覚でJestのモックライブラリを使おうとすると違和感というのか、モックへの考え方の違いに気づかされる。 ということで今回は、Jestのモックライブラリの考え方と使い方を整理していきたいと思う。 モックの用語整理とJestモックライブラリの位置づけ モックと一言でいっても、それが指す内容は微妙に異なる。 ここでは、モックを 広義のMock Object と 狭義のMock Object と分けて整理してくれているテスト駆動開発を参考に用語を整理する。 テスト駆動開発では、モック用語を、下図のとおり、テストダブルとそのサブクラスとして
テストデータを貯めて感じたこと
https://toruby.connpass.com/event/286678/ の発表資料です。
E2Eテストを Playwright で作り直して開発プロセスに組み込む話 - SmartHR Tech Blog
こんにちは。SmartHR プロダクトエンジニアの sasaki (@s_sasaki_0529) です。 今回は、私が開発に携わっている届出書類機能における E2E テストを、Capybara + Selenium の構成から Playwright に移行し、開発プロセスに組み込んだお話をします。 扱う話題 E2Eテスト基盤を移行する具体的な背景と理由 移行における提案から、合意形成までの流れ 移行後の開発プロセスがどう変わったか 扱わない話題 Playwright など、記事内で扱う技術要素自体の詳細説明 移行作業自体の詳細 テストコードの設計・実装に関する具体的なテクニック なお、本記事では便宜上、移行前の E2E テストを「旧テスト基盤」移行後を「新テスト基盤」と呼称します。 届出書類機能について E2Eテストに限らず、テストというのはプロダクトの特性によって最適な手法は大きく変わ
開発イテレーション偏重 - 兼雑記
開発イテレーションを早くすれば、かなりの問題が勝手に解決される、と信じています。なんか最近、他の要素を軽視しすぎていたり、特にイテレーション速度に影響しなさそうなことすらしている気がしていて、信仰とかのレベルかもしれない、という気がしてきたので、ちょっと書いてみようかなと。主に C++ の話です。 仕事とかしてると良い判断力が求められたりしますが、判断というのは結構難しいですよね。アプローチ A と B で悩んだ時に、手が速ければ両方できたりします。開発イテレーションを無限に速くすると、必要とされる判断力はゼロに漸近していきます。やったね。 2手で変更の正当性を高速に確認できるようにする make (かその他のビルドコマンド)てやったらビルドができて、 make check (かその他のテストスクリプト)てやったら遅くないテストが全部走る、という体勢が好きです。試すためにはあっちのディレク
はじめに こんにちは。ソーシャル経済メディア「NewsPicks」の QA/SET チームの海老澤です。 先日 弊社で E2E テスト実行するために Playwright を導入したため紹介させてください。 E2Eテストとは E2Eテスト（エンドツーエンドテスト）とは、ソフトウェア開発におけるテスト手法の一つで、アプリケーションが実際の運用環境と同様の条件下で正しく動作することを確認するためのテストです。 システムの開始点から終了点までを通じて、ユーザーの視点でアプリケーションのフローを追い、機能全体が連携して期待通りに動くかを検証します。具体的には、ユーザーが行うであろう一連の操作をシミュレートして、データがシステムを通じて適切に流れるかや、最終的なアウトプットが正しいかどうかを確認します。E2Eテストにより、部分的な単体テストや統合テストでは見逃されがちな問題を発見することができます。
みなさん Fuzz testing ってご存じでしょうか。 人間が作る物は必ずといっていいほどバグが存在します。そしてそのコードをテストする人間も必ずバグを見逃します。 想定していなかった境界値テスト等、人間には先入観という物があり、それが邪魔をして簡単にバグを見逃します。昨今、この様な誰も気付かなかったバグの隙間を突く様な脆弱性が沢山見つかっています。 物によっては重大インシデントに発展する物まであります。 こういった人間では想定できない様なバグを見付けてくれるのが Fuzz testing です。Fuzz testing を実施する事で、ソフトウェアは頑丈になり安全にもなりえます。 本日、Go の master ブランチに Fuzz testing の機能が入りました。 [dev.fuzz] Merge remote-tracking branch 'origin/dev.fuzz'
Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - 電通総研 テックブログ
みなさんこんにちは、電通国際情報サービス（ISID）Xイノベーション本部ソフトウェアデザインセンターの佐藤太一です。 この記事では、VS CodeのDev Containerを使ってOSに依存しないPythonの開発環境を構築する方法をステップバイステップで丁寧に説明します。 VS Codeの利用経験があり、またPythonによるアプリケーション開発に興味のある方を想定読者として記述しています。Pythonの初心者から中級者向けを意識して書いていますので、意図して冗長な説明をしています。 すでにPythonによるアプリケーション開発に十分に詳しい方は、まずはまとめだけ読んでみてください。私自身それほどPythonのエコシステムに詳しいわけではありませんので、知識の抜け漏れは恐らくあるでしょう。そういった事に気が付いたら、XなどのSNSでこの記事のURLを付けてコメントをしていただけると幸い
TechFeed Experts Night#2 〜 フロントエンドフレームワーク特集 https://techfeed.io/events/techfeed-experts-night-2 Twitter https://twitter.com/__sakito__
プログラマーテストの原則 by Kent Beck
チョコレート対バニラTDD対BDD。このテストツール対あのテストツール。テストビフォー対テストアフター対これは動くから俺を信じろ。ある時期から、こうした詳細に関する議論には飽きてしまった。もっと原則について議論したい。 詳細に関する議論はなかなか結論に至らずに、話が行ったり来たりする。チョコレート対バニラ。チョコレート。バニラ。チョコレート。バニラ。 詳細の議論に負けを認めさせられるようなことがあっても、その譲歩は絶対的なものではない。私の状況がチョコレートを勧めているのに、私にバニラを食べさせてくれと言えるだろうか？ これでは埒が明かない。 原則一方、原則は議論を生み出す基盤になる。原則には賛成しても状況が違っているのなら、答えは違ってくるかもしれないが、そこで論争になることはない。原則が、異なる状況における異なる答えを生み出したのである。 詳細で論争するよりも、原則で論争したほうが生産
デザインとHTMLのズレを検出！ Node.jsとPuppeteer活用のビジュアル校正テストで実装時のケアレスミスを防ぐ ウェブ制作において、デザインとHTML実装の一致はエンジニアとして当然求められるものです。とはいえ、デザインツールとブラウザ画面をにらめっこしながら確認するのも大変です。本記事ではNode.jsで動くヘッドレスブラウザのPuppeteerパペティアーを使ってデザインとのズレを検知するビジュアル校正テストの方法を紹介します。 ウェブ業界ではデザイン制作とHTML制作が分業である場合がほとんどです。ビジュアル校正テストを導入することで、HTML制作の品質向上に役立てられます。デザインとHTML実装が別の会社のようなプロジェクトでは、HTML実装時の品質保証の担保になりますし、デザイナーとフロントエンドエンジニアが近い組織でもコミュニケーション円滑化に役立つでしょう。ICS
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: 37signals Dev — Pending tests 原文公開日: 2023/03/01 原著者: Jorge Manrubia -- 37signalsのエンジニアです 日本語タイトルは内容に即したものにしました。 私は「テストファースト」で作業することも、テストでコードの設計を支援することも、めったにありません。 最近の私は、37signalsである新しいことに取り組み始めました。何も決まっていない白紙の状態なので作業はすいすい進み、来る日も来る日もこってりしたプルリクを作成しています。会議に先立って早めに投げておきたいと思っていたプルリクには、もれなく以下が含まれていました。 ご覧のように、私はほとんどの場合テストを最後に書いていることが見て取れます。例外があるとすれば、テストを書くことで最短で結果をフィードバックで
はじめに こんにちは。ブランドソリューション開発本部FAANSバックエンドブロックの佐野です。普段はサーバーサイドエンジニアとして、FAANSのバックエンドシステムを開発しています。 FAANSとは、弊社が2022年8月に正式ローンチした、アパレル店舗で働くショップスタッフの販売サポートツールです。例えば、コーディネート投稿機能や成果確認機能などを備えています。投稿されたコーディネートはZOZOTOWNやWEAR、Yahoo!ショッピング、ブランド様のECサイトへの連携が可能です。成果確認機能では、投稿されたコーディネート経由のEC売上やコーディネート閲覧数などの成果を可視化しています。 本記事では、成果データの集計処理におけるBigQueryのクエリ実行処理のユニットテストをGoで実装した取り組みと、その際の工夫についてご紹介します。 目次 はじめに 目次 成果データの集計処理とは 抱え
株式会社ラクスが開催するエンジニア向けのイベント「RAKUS Meetup」。今回は「SaaS新規プロダクトの技術」をテーマに、同社プロダクト「楽楽労務」の開発を担当する福岡憲治氏が登壇し、「新規プロダクトの開発速度と品質の両立を支える自動テスト」という内容で話をしました。 新規プロダクトならではの悩み 福岡憲治氏（以下、福岡）：それでは『新規プロダクトの開発速度と品質の両立を支える自動テスト』というタイトルで福岡が発表いたします。お願いします。 ではいきなりですが、まずはじめに、新規プロダクトとタイトルに入っているとおり、新規プロダクトならではの悩みについて、簡単にお話しできればと思います。 まず1つ目、ドメインに対する理解が不十分だったり、アジャイルに機能開発していくので、作り直しが発生します。あるいは、新規プロダクトである程度できあがってくると、チームメンバーを増員することになります
最近MailosaurというSaaSを使ってメール送信機能をテストしてみましたので、備忘がてら紹介メモを残しておきます。 Mailosaurとは? Mailosaurとは Email and SMS testing platformだそうです。 mailosaur.com メールがちゃんと送れているか?だとかメール本文/添付ファイルなどは意図通りか?をテストするのに便利な機能が提供されています。 Mailosaurってなんて読むの? 以下の動画をみたところ、カタカナだと「メイラソー」のように呼ばれていました。 www.youtube.com どんなことができるの? EメールやSMS関連のテストを行うための様々な便利機能が提供されています。 詳細は以下のドキュメントに記載されています。 mailosaur.com 例えばEメール関連ですと以下のような機能が提供されています。(上位プランのみの
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
小さなバグが生んだ悲劇、そこから学ぶ耐障害性の高いアプリ設計
Puppeteerで不要なCSSを消す - Cybozu Inside Out | サイボウズエンジニアのブログ
Should I Test Private Methods?
(修正版) NumPy/pandas使いのためのテスト自動化入門 / PyConJP2020
同じソースツリーでテストが通っていたらテストをスキップする | おそらくはそれさえも平凡な日々
リファクタリングが先か、テストが先か - E2E自動テストの理想と現実 ｜Autifyブログ
新しい UI テストの手法を提供するテストライブラリ SafeTest
理想のフロントエンドテストをたずねて三千里 - カミナシ エンジニアブログ
JestのTips集10選。サーバーサイドでNode.jsのJestを書いたことない人向け
なぜJestのmockライブラリに混乱してしまうのか？ - Qiita
Playwrightを使ったE2Eテストを導入した話 - Uzabase for Engineers
Big Sky :: Go に Fuzz testing が入った。
Reactコンポーネントにおけるテスト手法の選択肢
デザインとHTMLのズレを検出！ Node.jsとPuppeteer活用のビジュアル校正テストで実装時のケアレスミスを防ぐ - ICS MEDIA
私がTDDを実践しない理由（翻訳）｜TechRacho by BPS株式会社
GoでSQLの複雑なクエリのテストを書いてみた - ZOZO TECH BLOG
“テストコードを書く文化”をどう形成していったか 開発速度と品質の両立を支える3つの「自動テスト」とは
Mailosaurでメール送信のE2Eテスト - febc技術メモ
cosmos196102.blog.fc2.com
shonenjumpplus.com
calligraphy-shodo.hatenablog.com
www.sankei.com
setsuyakufuansyougai.hatenablog.com
mainichi.jp