欠陥を早期に発見するための Software Engineer in Test とその重要性 / What is Software Engineer in Test and How they works＠IT 開発変革セミナー 2024 春 ～Spring～ ～効率化、コスト削減にとどまらない、システム開発の在るべき姿～ 基調講演2 https://members09.live.itmedia.co.jp/library/Njc3Nzc%253D
テストピラミッド万歳 | POSTD
クイックサマリー：「テストピラミッド」は、自動テストをUI、サービス、ユニット単位に整理することで、開発に自動テストを組み込む方法を示すために作成されました。2012年に定義されて以降、このモデルは次第に使われなくなってきたように思いますが、本当に廃れてしまったのでしょうか。この記事では、最新のテスト戦略を紹介するとともに、今日のソフトウェア開発におけるテストピラミッドの関連性を検討します。 筆者の同僚であるジャン・フィリップ・ピエトルチェクが、かつてコードを書く開発者の責任について、次のように述べました。 none「我々の仕事の成果を最終的に使用する人々は、（中略）我々がただ最善を尽くすだけでなく、実際に機能するものを作ることを期待しているのです。」 — ジャン・フィリップ・ピエトルチェク 彼の言葉は、私たちが書くコードをそれに依存する人々の観点からとらえている点で非常に印象に残りました
🥇Golden Testを導入してUI開発の不安を解消する
はじめに Flutter好きの皆さんこんにちは！ アルサーガパートナーズ株式会社でFlutterエンジニアをしているtaiseiです！ 突然ですが皆さん、FlutterでUIの開発を進める中で、「このUIはどんなデバイスでも適切に表示されるのだろうか..?」と不安に感じたことはありませんか？ レスポンシブデザインはもちろんのこと、テキストのフォントや色、ダークモードの表示など複数のデバイスで複数の画面を一回一回チェックするのは骨の折れる作業ですし、開発を進める中で副作用によってUIが変更され、気付かないうちに開発が進んでしまうといったこともあります。 そこで、これらの問題を解決する方法として、Golden TestというUIテスト手法があります！！ 今回はこのGolden Testについて、設定から基本的な使い方、私が実際に遭遇したエラーに対するトラブルシューティング等を解説していこうと思
情報処理技術者試験の答案を開示請求した話 - Qiita
（1）はじめに 応用情報技術者試験・高度情報処理技術者試験・情報処理安全確保支援士試験の答案、特に記述式・論述式の午後試験に自分が何を書いたか知りたいと思いませんか。記述式試験の解答は、時間が余ればメモできますが、論述式（小論文）の試験は時間的に不可能です。 そこで、情報処理推進機構（IPA）に対して保有個人情報開示請求を使って、自分の答案を取り寄せてみました。手続方法は、IPAのサイト https://www.ipa.go.jp/privacy/seikyu.html に書かれていますが、実際にやったことを書いておきます。 ちなみに、試験対策参考書の小論文解答例は、著者が何日もかけて考え、PCで推敲を重ねて書いたもので、ある意味「完璧な」答案です。これに対して、試験本番は2時間で手書きするものですから、完璧な答案は望むべくもありませんし、完璧でなくても合格できるのです。自分の見直しや、社
テストコードの改革を進めている話 | メルカリエンジニアリング
はじめに この記事は、Merpay Tech Openness Month 2023 15日目の記事です。 こんにちは。メルペイ加盟店精算チームのバックエンドエンジニア@r_yamaokaです。 今日は現在自分がリードして取り組んでいるテストコードの改善について紹介したいと思います。 抱えている課題 私が所属している加盟店精算チームのマイクロサービスは加盟店さま向けサービスとして欠かせないものであり、メルペイ最初期から存在するサービスです。他のマイクロサービスにあまり無い特徴として多数のバッチ処理を行っている点が挙げられます。 お客さま（メルペイユーザー）がお店で行った決済は、一定の頻度で集計し決済手数料を差し引いた上で加盟店さまの銀行口座へ振り込むことになります。 最終的な振込金額を算出するまでの流れとしては 個々の決済金額のリコンサイル（会計マイクロサービスとの金額照合） 日次集計 締
フロントエンドテストにおける知見の宝庫を発見！「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 想定読者 フロントエンドの実装はできるが、テスト経験はない方 テストに対して解像度が低い方 これからテストを学びたいと思ってい
フロントエンドテストにおける知見の宝庫を発見！「javascript-testing-best-practices」 - Qiita
フロントエンドテストにおける知見の宝庫を発見！「javascript-testing-best-practices」JavaScriptテストフロントエンド はじめに 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 Test
私のフロントエンドディレクトリ構成・テスト観点 2022
近日連投していた Next.js 記事のサンプルコードを公開しました。このサンプルコードを元に、私のフロントエンドディレクトリ構成・テスト観点を紹介します（あくまで執筆現在の脳内アウトプットになりますのでご了承ください） フロントエンドディレクトリ構成の事情 タイトルの「フロントエンドディレクトリ構成」をさす「Components」のディレクトリ構成は、いつも悩みのタネです。このモジュールシステムは「デザインシステム観点・アクセシビリティ観点・フロントエンド実装観点」の 3 つの観点が混在するため事情が複雑です。どうせ作るのなら「デザイナー・フロントエンド」どちらの開発基盤にもなりえる、盤石なモジュールシステムを目指したいですよね。 "AtomicDesign やめました"という声をたまに聞くのですが「デザインシステム的に捨てていいの？」と思うこともあるので、とくに要望がなければ、筆者は「
E2Eテストのテスト結果を可視化することで気づきが生まれた | メルカリエンジニアリング
メルカリの自動化＆品質保証グループ（Automation & QA Group：通称AQA）の おれたま@AHA_oretama です。 私は普段、テスト自動化やCI / CD を主に行っています。 今回は、Appium×Android E2Eテストのテスト結果の見やすさを改善し、テスト結果を可視化することで気づきが生まれた話について、紹介していきたいと思います。 テスト結果の見やすさ、可視化の重要性について いま使っているテストレポートの課題 Allure Framework 並列化した分だけレポートも分かれてしまうことへの対処 スクリーンショット、スクリーンレコード以外のアタッチメントを追加することができないことへの対処 過去のテスト結果と比較できないことへの対処 他の改善点 テストのタイムラインが見える トレンドも表示できる Looker 生まれた気づき 課題 終わりに テスト結果の
モックは必要悪で、しないにこしたことはない - blog.8-p.info
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
フロントエンドテストプラクティス in open 8
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
テストを自動化するのをやめ、自動テストを作ろう
July Tech Festa 2020 TrackB https://jtf2020.peatix.com/
結合テストと呼ぶのをやめた話 - asterisc
はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類（small / medium / large）に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
