はじめに よく言われるように、ソースコードというものは書かれることよりも読まれることの方が多く、それゆえ読みやすいコードを書くということが非常に重要です。それはテストコードにおいても同様であり、プロダクトコードと同等に資産として扱う必要があります。 テストコードは具体的な値を用いて記述し、また複数の変数の値の組み合わせでテストケースを起こすため、プロダクトコードと比べて冗長になりがちです。 書籍『リーダブルコード』の14章でもテストコードの読みやすさについて触れられていますが、本稿では読みづらいテストコードをリファクタリングして読みやすくするためのテクニックを紹介したいと思います。 なおサンプルコードはJavaScriptで記述されており、そのテストコードはJest1を用いて書いています。 ソースコードはGitHubにあります。 リファクタリング(その壱) 以下の、決して読みやすいとはいえ

以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P…

ソフトウェア開発において、不確実性にどのように立ち向かっていくかは大きな課題です。 PHPerとしては、開発中にいかにコード品質を上げるかといったことは大きな関心で、その一つの規律のとり方としてTDDを実践されてきた方は多いのではないでしょうか。 トークの表題であるATDDは、Acceptance Test Driven Developmentの略です。TDD Cycleよりももう一つ大きなスコープでのフィードバックループをテストによって駆動します。特にアジャイル開発の文脈で「Agile Testing」という一つのテーマ内で紹介されることが多い手法です。 ユニットテスト・コンポーネントテストをカバーするテストによって開発を駆動するTDDに対して、ATDDはよりビジネスフォーカスの強いテストによって開発を駆動します。ATDDの開発プロセスの実践によって、技術レイヤ横断的な製品全体の回帰テス

組織としてテスト自動化に取り組むべき理由と、手段としてのテスト駆動開発を紹介する講演資料です。以下のような内容です。 ねらい： ・主に顧客向けの業務システム(B2B)を開発している、 ・プロジェクトベース、ウォーターフォールプロセスが主流の開発現場や運用保守の現場にいる、 ・マネージャーのかたに向け、 ・テスト自動化が自分たちのメリットになると納得してもらい、 ・その道筋として2つのアプローチを紹介して、 - テスト駆動開発 - ペアプログラミング ・組織的・長期的に取り組む価値を感じてもらう アジェンダ: 1.自動化したい理由 2.必要な人材を考える 3.テスト自動化の端緒 ～テスト駆動開発について～ 4.深めつつ広げる鍵 ～ペアプログラミングについて～ 5.見る夢について

以下のイベントの投影資料です。 https://devlove.doorkeeper.jp/events/112966 実際の発表で説明した「実例マッピング」の部分は、別スライドにしています。こちらもどうぞ。 事例から学ぶ実例マッピングのやり方 https://speakerdeck.c…

https://docs.google.com/presentation/d/1SEYB7EA0uw0ARGfiC3pkY9m4KFw0m8Myng3Fc29cFvU/edit?usp=sharing

はじめに（Testing Manifestoを紹介するに至った背景） 既にこのブログでお伝えしたように、先日『Agile Testing Condensed』の日本語翻訳本を出版しました。 この書籍の中で、テストマニフェスト（Testing Manifesto）が紹介されています。 アジャイルソフトウェア開発宣言（Agile Manifesto）を元ネタにして作ったものだと思います。 この考え方は書籍を購入していない人にもぜひ知ってほしいと感じているので、この記事でも紹介することにしました。なお、記事に載せることについては、この画像の作者であるKarenとSamにメールを送り許諾を得た上で掲載しています。*1 テストマニフェスト 翻訳した画像はこちらです。*2 オリジナルの画像等はこちらにあります。 www.growingagile.co.za また、画像だけでなく文章も残しておきます。

本記事はModern Best Practices for Testing in Java の日本語訳です。元記事の著者から許可を得て翻訳、公開しています。 翻訳は不慣れなので変なところもあると思いますが、ご容赦ください。 なお、はてなブログにも同じ記事を投稿しています。 https://dhirabayashi.hatenablog.com/entry/2020/04/21/190009 メンテナンスしやすくて読みやすいテストコードは良いテストカバレッジを確立するために重要で、それにより何かを壊すことを恐れずに新機能の実装やリファクタリングが可能になります。この記事には、私がJavaでユニットテストや統合テストを長年に渡って書いて得られた多くのベストプラクティスが含まれています。それにはJUnit5やAssertJ、Testcontainers、Kotlinといったモダンな技術も含みます

JaSST'20 Tokyo RejectCon

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

In DevOps, test is required to be automated. multi-browser testing is also so. However, multi-browser testing is not easy now. To guide you to multi-browser testing, I create "Multi-Browser Testing Strategy Map". You should grow your multi-browser testing and find your best position in "Multi-Browser Testing Strategy Map".

Hiroyuki Ito2018-07-08LINE株式会社のSET（Software Engineer in Test）です。「SETタスクフォース」（以下「SETチーム」と表記）のリーダーとして、主にLINEプラットフォームのサーバーサイドで、テスト自動化を活用したプロダクト開発ライフサイクルの改善を立案・実施・主導しています。また、アジャイルコーチも兼務しています。 はじめに こんにちは。LINE株式会社のSET（Software Engineer in Test）の伊藤 宏幸（Hiroyuki Ito）です。 2018年6月27日（水）に、電気通信大学の西 康晴さん（以下「にしさん」と表記）をお招きして、「Testing & Engineering」をテーマに「LINE Developer Meetup Tokyo」を開催しました。 この記事では、イベント企画者 兼 登壇者の立場か

1. 1Copyright © Acroquest Technology Co., Ltd. All rights reserved. マイクロサービスにおけるテスト自動化 with Karate 2018/12/08 Acroquest Technology Co., Ltd. 鈴木 貴典 システムテスト自動化カンファレンス 2018 2. Copyright © Acroquest Technology Co., Ltd. All rights reserved. 2 自己紹介 ◼ 所属 • Acroquest Technology Co., Ltd. ◼ 主な業務分野 • システムアーキテクト • IoTサービス開発 • ビッグデータ処理プラットフォーム • サーバーレス・アーキテクチャ ◼ バックグラウンド • エンタープライズ／ミッションクリティカル • SEPG／開発／マネジメ

re:Invent2018のカオスエンジニアリングについてのセッション、AWSのモダンアプリケーションに対するカオスエンジニアリングにて、Gremilinというサービスについての紹介とデモがありました。 サービスについて気になったので、本記事ではドキュメントをみながらGremlinについてまとめてみます。 Gremlinの概要 Gremlinはシステムの弱点を見つけるためにシステムに障害を注入するためのサービスです。 インフラもしくはアプリケーションレベルでの障害を注入することができます。 Gremlinは、システムの弾性を得るためのカオスエンジニアリングの実践を、安全、シンプル、セキュアに提供します。 Gremlinでどんな障害を起こせるのか？ 大きく以下の3つのカテゴリがあります。 Resource Gremlins Network Gremlins State Gremlins 各攻

SendGridサポートエンジニアの菊田(@kikutaro_)です。メール送信処理を実装するとき、皆さんはどのようにテストをしていますか？個人やテスト用のメールアドレス宛てに送ることが多いと思いますが、メールのテストには様々な方法があります。今回のブログでは、メールのテストで役に立つツールやサービスを紹介します。 テスト用のSMTPサーバ メール送信のテストでよく使われるのがダミーのSMTPサーバです。通常のSMTPサーバは、メールの送信リクエストを宛先サーバに届けますが、ダミーのSMTPサーバは実際のメール送信はせずに、送信リクエストの受付結果を出力するだけです。 GUIベースのツール 次のようなものがあります。 FakeSMTP MailCatcher Papercut MailDev 以下はFakeSMTPの画面です。ローカル環境で起動して、メール送信プログラムの接続先SMTPには

皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか？少なくとも私は今までテストカバレッジ100%を追求していました。「C0/C1カバレッジ100%」がユニットテストの完了条件として含まれているプロジェクトも多いかと思います。 本稿では、「カバレッジが高ければ、ソースコードの品質が高い」という命題がなぜ誤っているのかを論理的に証明し、カバレッジを計測する本当の目的、そして推奨されるカバレッジの目標値について紹介したいと思います。 「カバレッジが高ければ、ソースコードの品質が高い」はなぜ間違っているのか？ カバレッジを計測する本当の目的 バグを潜在させてしまう恐怖のテストケース・アンチパターン カバレッジの目標値は100%にするべきではない カバレッジの目標値は何%にするべきなのか？ （テストカバレッジの種類については『ホワイトボックステストにおけるカバレ

Testing in ProductionとMonitoring Driven Developmentについて調べたまとめ サーバーレス開発部の阿部です。 今日はサーバーレス開発のテストにつきまとう課題について調べていたらたどり着いた言葉であるTesting in ProductionとMonitoring Driven Developmentを取り上げてみようと思います。 【背景】サーバーレス開発のテストにつきまとう課題 以前、Serverless ArchitectureとMicroservice Architectureの違いに触れた時に、Serverless Architectureの特徴としてマネージドサービスを使い倒すことをあげました。 マネージドサービスは便利なのですが、使い倒すという観点になるとこれがなかなかに曲者です。以前サーバーレス開発部の和田もこのような記事を書いてお

24. 24 # iptables -A OUTPUT -p tcp -d xxx.xxx.xxx.xxx --dport 3306 -j REJECT

Less Code, Less Maintenance, More Acceptance Testing Gauge is a free and open source test automation framework that takes the pain out of acceptance testing Gauge + Taiko = Reliable browser automation for your JavaScript tests! Create readable and maintainable tests Gauge tests are in Markdown which makes writing and maintaining tests easier. Reuse specifications and robust refactoring to reduce d