LEADING QUALITY | Ronald Cummings-John, Owais Peer, 河原田 政典 |本 | 通販 | Amazon
「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 を紹介するツイートにもそういった反応が寄せられていた。（ぶんぶんさん、教えてくれてありがとうございます。） （このサイト面白すぎますよね・・・） 自分の立場を
良いテストケースの作成手法を学ぶ - 「はじめて学ぶソフトウェアのテスト技法」を読んだ - $shibayu36->blog;に引き続き、ソフトウェアテストの知識について言語化を進めたいと考え、「単体テストの考え方、使い方」を読んだ。 単体テストの考え方/使い方 作者:Vladimir Khorikovマイナビ出版Amazon この本では優れたテストスイートの4本の柱を「退行に対する保護」「リファクタリングへの耐性」「迅速なフィードバック」「保守しやすさ」と定義し、これらの観点で優れたテストスイートを作る方法について教えてくれる。またこの4つの柱はトレードオフの関係にあるため、単体テスト・統合テスト・E2Eテストがそれぞれどの観点を重視すべきかなどについても言語化してくれている。 自分はこの本は非常に勉強になった。なぜなら単体テスト・統合テストの指針が明快に記述されていて理解しやすく、また
Author’s Note: Thanks, as ever, to Fred Hebert, for reading a draft of this post and making some sterling suggestions. This is the first installment in my series on testing distributed systems. The posts in this series are the following: Testing Microservices, the sane way (published December 2017) Testing in Production, the safe way (published March 2018) Testing in Production: the hard parts (pu
テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー：多くのエンジニアに愛される理由とは 『【この1冊でよくわかる】 ソフトウェアテストの教科書 [増補改訂 第2版]』は、初版の発行部数は22,000部、2021年8月出版の改訂版は13,000部に上り、技術書としては異例のシリーズ累計35,000部を突破しました。（2023年6月現在） ソフトウェアテスト専門企業であるバルテス株式会社の技術者が執筆した、ソフトウェア開発工程のテストについて、基礎からしっかり体系的に学習できる本格入門書です。 このストーリーでは、初心者から上級者まで幅広い層に読まれている、ソフトウェアテストのバイブルともいえる本書完成までの経緯や苦労話、著者であるバルテスの石原 一宏氏と布施 昌弘氏が伝え続けたい想いをお伝えします。 テスト設計に必要な考え方を身につけられ
初めまして、購買ソリューショングループ 運用・機能改善チームの稗田です。当社では自社で運営しているECサイト(モノタロウドットコム)から直接商品をご購入いただく他に、他社の購買システムと連携して商品をご購入いただくシステム(大企業連携システム)があります。こちらの大企業連携システムには多くのバッチ処理があるのですが、これまで自動テストがありませんでした。今回はバッチ処理の障害をきっかけに短期間でユニットテストを充実させるためにした工夫や学んだことをお話しします。 ユニットテストを作らなければいけないと思ったきっかけ 障害発生 担当システムやチームの状況 チームの1人として感じたこと お客様やステークホルダーの信頼を取り戻すために ユニットテストを短期間で作成するためにやった工夫 工夫1: 外部協力会社の力を借りる 工夫2: 課題や目的、ルールをドキュメントで共有する 工夫3: リファレンス
こんにちは。決済チームでエンジニアとして働いている芦川です。 UPSIDER Tech blog 第2弾として「決済チームがテストコードを書く際に気をつけていること」を紹介しようと思います。 TL;DR 100％のテストカバレッジを目指す テストはブラックボックスを優先して記述、どうしても到達できない場合はホワイトボックス 最初のテストケースは、テスト対象が動作する最も一般的なケースであるべき 私たちは日々大量のコードを書いており、そのシチュエーションは多岐にわたります。 そういった環境において、動作確認からのコード改修のコストを考えた場合、自動テストの有無によって生産性に大きく差が出ることは容易に想像ができます。また、既存のサービスに改修を加えるために、そのサービスの概要を把握したい場合、良いテストコードはドキュメントとして役立ちます。 以前、私はテストコードを一切書かないプロダクトの開
■参考 ・JSTQB ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応 ・業務でも活用できるソフトウェアテストの7原則 ・Agile Testingのエッセンス ・TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング ・テスト駆動開発 ・BDDとATDD ・The BDD Books - Discovery (Japanese Edition) ・リーダブルテストコード ・テストコードにはテストの意図を込めよう ・組織にテストを書く文化を根付かせる戦略と戦術（2020秋版） ・質とスピード（2022春版、質疑応答用資料付き） ・【翻訳記事】テストに対する考え方「Testing Manifesto」 ・マネジメント向けアジャイル開発概要 ・The Software Testing Ice Cream Cone ・Goo
先日、「リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～」というイベントで登壇してきました。 veriserve-event.connpass.com 今回は発表内容に対する補足と、発表に対していただいた質問に回答します。気になるところだけでも読んでもらえればと思います。 目次 目次 発表内容 発表に対する補足 【補足1】都道府県のテストについて 【補足2】Parameterized Testsへの利用について いただいた質問の回答 【質問1】リーダブルなテストコードの勉強方法はありますか？ 【質問2】テストコードのメンテナンスをするにあたってのリファクタリングの頻度はどれくらいか？ 【質問3】レビューをする際、機能自体のレビューにかけた時間に対してテストのレビューにかける時間はどのくらいの割合で行っていますか? 【質問4】
「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 http…
この記事は Merpay Tech Openness Month 2022 の15日目の記事です。 はじめに こんにちは。Credit Design Teamでバックエンドエンジニアをしている@tanaka0325です。主にメルペイスマート払いの開発をしています。 この記事では、先日私のチームで作成したユニットテストのガイドラインについて紹介します。 課題 現在私が担当している「メルペイスマート払い」のマイクロサービスは、もともと「メルカリ月イチ払い」として提供されていたコードを流用し、新規要件となる機能を追加して作られたマイクロサービスです。 マイクロサービス化するにあたり、「メルカリ月イチ払い」にあったデータはマイクロサービスリリース後に随時マイグレーションをする方針になったので、既存のデータをマイグレーションしつつ、定額払いなどの新規機能を追加してきました。メルペイスマート払いのマイ
社内用の啓発記事ですが、閉じる理由がないのでここに投げます。 ブラウザにべったりなコードを書いてると、ブラウザや 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
2014/12/09 に DeNA 社内勉強会にお招きいただいて話した内容です
動画はこちら https://twitter.com/_kensh/status/1468951162053607424?s=20 サーバーレスはサクっと作れるのは良いけれどテストやデバッグが大変だって思うことはないでしょうか？ 難しさの理由としてプログラミングコードのテストだけでなく、サービス…
こんにちは、鈴木です。 「テストが無い」状態を脱却しました。 「いつの時代かよ！」と突っ込まれるかもしれませんが、モノタロウは創業から 20 年ほど EC をやっています。昨日書いたコードも、15 年前に書いたコードも、元気にビジネスを支えています。 本記事ではモノタロウの EC を支える API の話をします。「テストが無い」状態がスタートラインでした。そこから、CI を導入して、ローカル開発環境の整備して、テストコードを書いて、リリースマネジメントを導入しました。 目新しいことは書きません。長寿の大規模システムであっても、愚直に数年取り組むことで、「前進できる！」「変えられる！」という実例を書きます。 ※本記事の初出は、 Software Design2021年9月号「Pythonモダン化計画（第2回）」になります。第1回の記事は「Software Design連載 2021年8月号
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
AWSアクセスキーセキュリティ意識向上委員会って何？ 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 本記事の想定読者 本記事ではフルマネージド型サービス=IAMを使ってアクセス制御を行うサービスと置き換えられます、これらを一切使わない開発(ALB, EC2, RDSのみなど)をしている方は対象外です 本記事はAWS上にソフトウェアを構築する開発者(主にバックエンドエンジニア)や開発環境を提供するプラットフォーマーを想定読者としています Typ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
