こんにちは。事業開発部の岡村 (@iceman5499) です。 普段はクックパッドアプリ（iOS）を開発しています。 先日、アプリケーションが特定の条件で意図せぬ状態に陥り、アプリケーションが重くなって端末が発熱する、というバグが発見されました。 調査の結果、このバグはメモリリークが原因で発生していました。 この反省を踏まえメモリリークを検知するテストを導入したため、本記事ではその事例を紹介したいと思います。 （本記事ではクックパッドアプリとはiOS版の「クックパッド」アプリのことを指すものとします） クックパッドアプリにおけるメモリリークの影響 クックパッドアプリはレシピの検索をコア機能としています。 検索は重い処理ですがAPIを通してサーバ上で行われるため、アプリは結果を表示するだけです。そのためメモリを多く必要としません。 これまでにも何度かメモリリークが発生している状況はありまし
単体テストの考え方/使い方|マイナビブックス
単体テストの考え方/使い方 プロジェクトの持続可能な成長を実現するための戦略 著作者名：Vladimir Khorikov 編集者名：須田智之 書籍：4,488円 電子版：4,488円 B5変：416ページ ISBN：978-4-8399-8172-3 発売日：2022年12月28日 内容紹介 質の高いテストを行い、ソフトウェアに価値をもたらそう！ 単体（unit）テストの原則・実践とそのパターン ― プロジェクトの持続可能な成長を実現するための戦略について解説。 優れたテストを実践すれば、ソフトウェアの品質改善とプロジェクトの成長に役立ちます。逆に間違ったテストを行えば、コードを壊し、バグを増やし、時間とコストだけが増えていきます。生産性とソフトウェアの品質を高めるため、優れた"単体テスト"の方法を学ぶことは、多くの開発者とソフトウェア・プロジェクトのために必須といえるでしょう。 本書“
TDDワークショップの開催 こんにちは。EC事業部エンジニアの@symmondsです。 2021年の10月に入社しEC事業部のCREチームで活動しています。詳しい活動内容については以前に記事を書いたので、興味がある方はぜひ読んでみてください。 GMO ペパボ(以下、ペパボ)では2021年に引き続き、今年も日本のTest Driven Development(TDD) の第一人者である @t_wada さんをお招きしてワークショップを開催しました。 「なぜTDDワークショップを開催したのか？」については、去年のTDDワークショップの記事で詳しく説明していますので、こちらをご覧ください。 研修内容 ここからはホスティング事業部の@matsusukeがご説明します。 2022年の3月にペパボに中途入社しました。最近はFall Guysにはまっていますが未だに一位が取れず、夜しか眠れません。 今回
プログラマでテスト駆動開発者の@t_wadaさんをお招きした社内勉強会での様子をお届け！＃メルカリな日々 | mercan (メルカン)
プログラマでテスト駆動開発者の@t_wadaさんをお招きした社内勉強会での様子をお届け！＃メルカリな日々 みなさん、こんにちは！メルカリのエンジニア組織の組織づくりや情報の可視化を担当しているEngineering Officeのaisakaです。 2019年12月18日に、プログラマでテスト駆動開発者の和田卓人（以下@t_wada）さんを社内にお招きし、社内勉強会を実施しました！ 内容は、先日行われたEOF2019 （Engineering Organization Festival）にメルカリの今の課題を取り入れ、アレンジしていただいたものです。EOF2019にて、メルカリから参加した@hidenorigotoさんと@jarinosukeさんの登壇記事はこちら！ 当日は120名以上のエンジニア、プロダクトマネージャー（PM）、コーポレートを含むメンバーが参加し、ランチを食べながらプロダ
Authors Note: Hey, we messed up in this post by referring to BUSL-1.1 as Open Source. We’re sorry, we are leaving this post as-is to keep the record clear and we’ve followed up in a new post. Since the beginning, the open source community has been a strong partner in Codecov’s growth and success. That’s why we always offered Codecov for free to use on any open source project. And if we’re being to
（私自身のテスト駆動開発については、こちらにまとめてあります） 一年以上、メルペイでウェブサービスのbackendのマイクロサービスを開発していますが、組み込み系のソフトウェア開発と異なり、短期間に新たな機能を開発してリリースすることが求められます。2週間のスプリント単位でリリースしていますが、一つのスプリントで数個の機能を開発することも普通になっています。現在は、ウェブブラウザのフロントにAPIを提供しているあるマイクロサービスを担当しているため、機能の追加は、既存のAPIの仕様変更だったり、新たなAPIの追加だったりします。 開発順序現在担当しているマイクロサービスは、その開発の当初から私自身が関わっていたものでないため、既存のコードを調査して理解する必要がある場合が多く、開発はおおまかに次の順序となります。 既存のAPIの仕様の記述の変更、もしくは、新たなAPIの仕様の記述 既存のA
こんにちは！ LIFULLのSETエンジニアのRueyです！ 今年の3月にISTQBの自動化エンジニア資格 CTAL-TAE(Advanced Level Test Automation Engineer)を取得しました。TAEの勉強で自動テストの効果を測るメトリクスが幾つかあることが分かりました。その中で工数を測るメトリクスをEMTE(Equivalent Manual Test Effort)単位で表現することが推奨されています。しかし、その時は説明を見てもこれに換算すれば何か嬉しいか分かりませんでした。 ちょうどある開発グループで自動テストを導入する案件がありましたので、実際のプロジェクトでメトリクスを計測し検証してみました。様々な知見が得られたので、今回はこの単位の紹介と使用例を紹介したいと思います。 目次 はじめに 自動テストのメトリクス EMTEとは EMTEを使って表すことが
Philipp Hauer's Blog Engineering Management, Java Ecosystem, Kotlin, Sociology of Software Development Posted on Sep 9, 2019. Updated on Dec 18, 2022 Maintainable and readable test code is crucial to establish a good test coverage which in turn enables implementing new features and performing refactorings without the fear of breaking something. This post contains many best practices that I collect
WEB+DB PRESS休刊に伴い、今回からWeb上で連載を継続させていただくことになりました。今後とも何卒よろしくお願いします。さて、あらためて本連載の最近の連載のテーマを振り返りますと、それは「信頼性の高い実行結果に短い時間で到達する自動テスト群を組み上げ、ソフトウェアの成長を持続可能なものにする」となります。今回はそのなかから「実行結果」に光を当てます。 多くのテスティングフレームワークには実行結果の出力フォーマットを変更するオプションやプラグイン機構があり、自動テストはその実行結果を様々なフォーマットで出力します。それらテストの実行結果は「情報」であり、情報の役割とは意思決定と行動を促すことです。テストの実行結果が促す行動とはデプロイ、マージ、コードの修正などです。今回は、そのようなテスト実行結果出力の種類と目的についてまとめます。 信号機としてのテスト出力 意思決定から行動へつな
Golang でスマートに標準出力テストを行う
Golang で標準出力テストの方法の調査 最近Golangで標準出力をテストする際にどのような方法を取れば良いのか情報も少なく、しばらく迷走していたので、ここで一旦メモとしてまとめておく。 標準出力をテストする方法を模索した結果 今回調査した方法は主に以下の2つ os.Pipe() を駆使して出力先を切り替えて値をキャプチャする Testable Examples を利用する os.Pipe() を駆使して出力先を切り替えて値をキャプチャする まず初めに、標準出力を受け取る関数を定義して、出力先を切り替えて値をキャプチャする方法が妥当であろうと考え、以下のような共通関数を定義して呼び出すことにしました。 func PickStdout(t *testing.T, fnc func()) string { t.Helper() backup := os.Stdout defer func(
MP3ファイルをダウンロード 内容紹介 twadaさんをゲストに、テスト駆動開発(TDD)、TDDに関するよくある誤解などを語っていただいたエピソードです。 出演者 話したネタ 【翻訳】テスト駆動開発の定義 自動テストとテスト駆動開発、その全体像 保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 テスト駆動開発とは何だったのか？ テスト駆動開発と同じレイヤの手法はある？ テスト駆動開発と品質保証との関連は？ TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング テスト駆動開発に関するよくある誤解 アジャイル開発との類似点（みんな丸い） IPAの試験での誤解 今回のブログを書いた（翻訳した）ことによる懸念 サバンナ便り ～ソフトウェア開発の荒野を生き抜く～ 記事一覧 書籍レビュワー募集フォーム
この記事は、 Merpay Advent Calendar 2021 の10日目の記事です。 本記事は、1週間リリースを支えるAndroid自動テスト運用についてメルペイ Androidチームの@amane, @kenken, @anzai, @hiroPがお送りします。 自動化の背景 メルカリアプリでは、お客さまに素早く価値を届ける目的で、2週間に1度のアプリリリースサイクルを1週間に1度に短縮することを目指しました。（リリースサイクルのアップデートに関しては@stamakiさんのこちらの記事を参照してください。） しかしこのサイクルを実現するには、2日間かかっていたリグレッションテストを1日に短縮する必要がありました。 そこで手動で実施しているテストの工数を短縮するために、自動化を始めました。 Androidのリグレッションテスト環境の構築 メルペイではFirebase Test La
継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣 作者:David Farley日経BPAmazon 書名の「継続的デリバリー」はCI /CDの解説書かな？とも思わせてしまうので若干ミスリードなんだけど、「工学とは何か？」「ソフトウェア工学とは何か？」「工芸と工学は何が違うか？」ということを解説した1冊。 『継続デリバリーのソフトウェア工学』を読み始めた そういえば、最近「ソフトウェア工学」ってキーワードを聞かないなーって思ってたけど、本書にも「最近敬遠されてない？」って書かれてた— magnoliak🍧 (@magnolia_k_) 2023年1月28日 まぁ、確かに「ソフトウェアの品質分析がー」とか、「設計書を書けばコードが自動生成ー」みたいな、「管理！」的な価値観が大きかったように思われてたんじゃないかなーとか思った— magnoliak🍧
始めに リンクアンドモチベーションでQAエンジニアをしています、代慶と申します。 先日のレガシーコード改善のワークショップに引き続き、和田卓人（t_wada）さんにTDDに関してワークショップを開催してもらいました。 本記事では、t_wadaさんが研修の中で頻度高く発言していた言葉や名言と共に、当日の研修での学びの概要を伝えていきたいと思います！ 当日の流れ 当日は、10人のエンジニアが10時から16時まで研修を受講しました。 前半は、座学メインで、適宜質問にも答えていただきました。 後半は、実習メインで、TDDの実践を行い、t_wadaさんとの公開1on1の時間を設けていただきました。 ※今回の講義は、前もってTDD Boot Campの動画の視聴も行い、よりTDDの理解を深めることができました。 TDDの概要 TDD（テスト駆動開発）とは・・・Red ⇒ Green ⇒ Refacto
自動テストに期待することはいくつかありますが、「失敗することで、テスト対象の動きが予期せず変わったことをプログラマーに教えてくれる」という役割は特に重要です。 この観点における期待外れの自動テストは2つ考えられます。失敗すべきでないときに失敗するテストと、失敗すべきときに失敗しないテストです。 失敗すべきでないときに失敗してしまうことを「偽陽性」（false positive）と言います。失敗すべきときに失敗してくれないことを「偽陰性」（false negative）と言います。今回はこの2つを整理します。 4象限で整理する 偽陽性と偽陰性は4象限で整理すると理解しやすくなります。プロダクトコードの正しさ、自動テストの実行結果（成功／失敗）という2つの軸で整理すると、表1ができあがります。 表1 偽陽性と偽陰性 偽陽性とは、プロダクトコードが正しいにもかかわらずテストが失敗してしまう
Springアプリケーションのテスト道具 使いどころ、使わないどころ / decide-to-use-test-tool-for-spring-application
SPRING FEST ’19 https://springfest2019.springframework.jp/
JestでHTTPリクエストをインターセプトしてモックを返すのに利用したMock Service Worker（msw）の紹介をしたいと思います。環境はNodeです。 テスト対象の実装 http://example.com/examples からデータを取得する、という想定の実装です。 import fetch from 'isomorphic-unfetch'; export class GetExampleError extends Error {} export async function getExamples(): Promise<string> { const result = await fetch('http://example.com/examples'); if (!result.ok) { throw new GetExampleError('Received ge
![[msw, Jest, Node.js] mswを利用してHTTP境界のテストを書く](https://cdn-ak-scissors.b.st-hatena.com/image/square/7509afad9c041929a9376082349cfd9a59870448/height=288;version=1;width=512/https%3A%2F%2Fog-image-lake-nine.vercel.app%2F%2A%2A%255Bmsw%2C%2520Jest%2C%2520Node.js%255D%2520msw%25E3%2582%2592%25E5%2588%25A9%25E7%2594%25A8%25E3%2581%2597%25E3%2581%25A6HTTP%25E5%25A2%2583%25E7%2595%258C%25E3%2581%25AE%25E3%2583%2586%25E3%2582%25B9%25E3%2583%2588%25E3%2582%2592%25E6%259B%25B8%25E3%2581%258F%2A%2A.png%3Fmd%3D1%26fontSize%3D100px)
初めに 具体的なコードや方法も記述しますが、それよりも JUnit などの自動テストのFW、ユニットテストの概念や目的など本質的なことを把握し理解する事を主題にしてます。 また、参考資料欄にあるように、様々なものを参考に網羅的にまとめています。非常にボリュームがるので興味あるところだけ読んでもらう方が良いかもしれません。 こちらでは、ある程度開発経験（1〜2年程度）があり、自動テストについて少しでも触れた事があるくらいの方が対象になる記事です。自分がそうだからです。ただし、コンパイルエラーにならないだけの書き方では意味がないのでそういった構文やお作法に関する話はあまりしません。なぜそのようなお作法になったのか？そうである理由は何なのか？トレードオフは？といった、本質的な部分にフォーカスを当てていきたいと思います。 1. 概要 JUnit は Java 言語向けのユニットテストフレームワーク
テスト駆動で学ぶ Firestoreセキュリティルール の書き方（認証、スキーマ検証、バリデーション） - Qiita
テスト駆動で学ぶ Firestoreセキュリティルール の書き方（認証、スキーマ検証、バリデーション）FirebaseJestFirestoreCloudFirestoreTypeScirpt 今までセキュリティルールをあまり書かずセキュリティ的にアレなものを量産していたので、 その反省からFirestoreのセキュリティルールについて学んだことを記します。 2020/12/01 追記 この記事は、以下バージョン時点の情報です。 node: 10.15.3 @firebase/testing: 0.12.3 内容案内 本記事では以下について記載しています。 Firestore セキュリティールールのテスト環境構築方法（TypeScirpt & Jest) ユーザー認証のルール記載方法、テスト方法 スキーマ検証のルール記載方法、テスト方法 値のバリデーションのルール記載方法、テスト方法 コー
本連載の主なテーマは、信頼できる実行結果にできるだけ短い時間でたどり着く自動テスト群の構築です。連載の区切りとして、なぜ自動テストを書いてメンテナンスしていくのか、そしてそれに立ちはだかる「脆いテスト」（fragile test）について整理します。 自動テストを書く動機 自動テストを書く動機には、不具合混入を防止する、問題箇所の絞り込みを容易にする、動く仕様書やサンプルになるなどいろいろありますが、最大の動機は、変化を抱擁し、ソフトウェアの成長を持続可能なものにすることだと筆者は考えています。 ソフトウェアを取り巻く世界は変わりました。ソフトウェアは世界を飲み込み、事業と一体化しました。事業を取り巻く市場もエンドユーザーのニーズも刻々と変化する時代においては、より速く、より安全に変化する力が求められます。コードを変更しなければ動き続けることが期待できる時代ではもうなく、決められたものを
最近のProduct Teamのペアプロ×TDDの文化をご紹介します - Uzabase for Engineers
はじめに はじめまして。Product Teamの中嶋です。今月からチームシャッフル*1でSPEEDAのR&D機能の開発を担当しています。 Product TeamではフルタイムでのペアプロとTDDを常に実践しています。 この話を社外でお話すると「どんな風にやっていくのかが想像つかない」とよく言われます。 私も前職で一時的にペアプロを導入することはありましたが、それを常にやり続けるというProduct Teamのペアプロ文化が入社するまで全く想像できませんでした。 そこで本記事ではProduct Teamがどのようにペアプロをしているのかをお届けしようと思います。 はじめに ツールについて ストーリーとペアはサインアップで決める まずはテストから書く 1時間に一度は休憩とペアチェンジを行う ソースコードのPushとデプロイ ソースコードのPushタイミングについて わからなければすぐ別のペ
エンドツーエンド テストの概要:Playwright。 Playwright は、Microsoft がオープンソースとして開発したエンド ツー エンド テスト用フレームワークで、モダンな Web アプリのテストに使用します。 この 6 部構成のシリーズでは、インストールから、テストの実行、記述、デバッグまで、関連するすべてを取り上げます。 Playwright を使うと、モダンな Web アプリに信頼性の高いエンドツーエンド テストを実行できます エンドツーエンド テストの概要:Playwright。 Playwright は、Microsoft がオープンソースとして開発したエンド ツー エンド テスト用フレームワークで、モダンな Web アプリのテストに使用します。 この 6 部構成のシリーズでは、インストールから、テストの実行、記述、デバッグまで、関連するすべてを取り上げます。 P
E2Eフレームワークとして高い人気を誇ってきたのがCypressです。使いやすいテストランナー、わかりやすいテスト結果、TypeScriptの組み込みサポート、プラグインによる拡張、(Seleniumと比較して)高速な実行などを提供しています。フューチャー社内でも使っているプロジェクトがいくつもあり、過去にCypress連載をブログ上で行い、それがきっかけとなってSoftware Designに連載も行いました。 一方で、現在人気が高まりつつあって、Cypressを追い抜こうとしているのがPlaywrightです。かなりCypressを意識して機能追加を行なってきている印象があります。現時点では特徴的なタイムトラベルデバッガー（過去の履歴すべてを保持しておいて気軽に前後DOMの状態を比較したりできる)、スクリーンショット、どちらもExperimentalなコンポーネントテストなど、できるこ
TDDで過去と戦った話 この記事はBASE Advent Calendar 2020 20日目の記事です。 devblog.thebase.in こんにちは。BASE BANK 株式会社 Dev Division にて、 Software Developer をしている永野(@glassmonekey )です。 今回は先日リリースした「BASE」上での売上情報をCSVでダウンロードできる売上データダウンロードAppの裏話的な内容となります。 タイトルにTDDとつけたものの、そこまでTDDの話は出てきませんのでご了承ください。 BASE( ᐛ )⛺️ 新しい機能「売上データダウンロード App」が誕生しました〜！👶🎉 売上にまつわるデータをCSVにてダウンロードすることが可能💡 またサービス手数料や、決済手数料についても確認することができます👍 利益の分析にも使うことができるので、ぜ
挨拶 こんにちは。2023年04月に入社した、minne事業部エンジニアの@kazuです。 この度、弊社GMO ペパボ(以下、ペパボ)では2022年に引き続き、今年も日本のTest-Driven Development(TDD) の第一人者である @t_wada さんをお招きしてTDDワークショップを開催しました。前回：『t_wadaさんによるTDDワークショップを開催しました』 なぜTDDワークショップを開催しているのかについては、こちらの記事『ふつうの開発と TDD ワークショップ』で詳しく説明していますのでご覧ください。 さて、それでは今回のTDDワークショップで何をしたのか、どんな気づきがあったのかなどについて、参加パートナーからそれぞれお話ししてまいります。 具体的な研修内容 概要 ワークショップは、事前に各参加パートナーが基調講演/ライブコーディングの動画を予習し、動画内でのラ
前置き この記事はBASE Advent Calendar 2020 13日目の記事です。 devblog.thebase.in こんにちは、BASE株式会社 Product Dev Division でバックエンドエンジニアを務めている元木です。 以前、社内で同僚のエンジニアと話していたとき、 「TDDって頭では分かっているけど、テストから書くってなかなか難しいよね」 という話がありました。 そこで、自分がTDDでプログラムを書くときに行なっているTips的なものを紹介してみたいと思います。 あくまで 「自分はこういう感じで実践している」 というものであり、 「これが正しいTDDだ！」 と主張するものではありませんので、軽い気持ちで読んでいただけたら幸いです。 そもそも、TDDとは？ テスト駆動開発 (Test Driven Development) のことです。いいね？ 本題 前置きが
JUnit5 使い方メモ - Qiita
package sample.junit5; import org.junit.jupiter.api.Assertions; import org.junit.jupiter.api.Test; import org.junit.jupiter.api.DisplayName; class JUnit5Test { @Test void fail() { Assertions.assertEquals(10, 8); } static class StaticClass { @Test void fail() { Assertions.assertEquals(10, 8); } } static class StaticTest { @Test void fail() { Assertions.assertEquals(10, 8); } } class InnerTest { @Te
Goのテスト安定性向上のためにFlakyなテストを再試行する機能を導入する提案 - tomato3713’s blog
Go言語にFlakyなテストへのサポートを追加する提案が面白かったので紹介します。 概要 Flakyなテストとは、コードに変更がないにもかかわらずテストが成功したり失敗したりと不安定な実行結果になるテストのことです。 テスト結果は本来なら全て成功ならリリース可能、1つでも失敗すればバグがあるのでリリース不可のようにリリースの可否を判断するための情報です。 そのため、不安定なテストは書かないようにすることが大前提です。 しかし、実際にはflakyであるとわかっていても修正が難しかったり、修正するための時間がないのでそのまま残すという判断をすることもあります。 Flakyなテストは削除するというのも手ではありますが不安定であってもテストが無いよりはマシとして残すこともあると思います。 github.com この提案では、Flakyなテストを扱うための機能を追加するものです。 初めの提案内容は、
こんにちは、今回からコラムを書かせていただく和田（t_wada）と申します。 現代のソフトウェア開発の対象領域は、広く複雑で不確実なものになりました。この連載では、自動テスト（Automated Test）に関わるトピックを中心に、ソフトウェア開発の荒野を生き抜いていくためのプログラミングやソフトウェアエンジニアリングの考え方を書いていきたいと考えています。 初回のテーマは、学習や調査が目的のテストコードを書くテクニック「学習用テスト」（Learning Test）です。では、よろしくお願いします。 二兎を追わない プログラミングのコツに、「一度に2つ以上のものを相手にしないこと」があります。 未知の技術を使って問題を解決するコードを書こうとするとき、私たちは2つのものと同時に戦うことになります。未知の技術そのものと、その技術を使った問題解決の2つです。2つ以上のものを同時に取り扱おう
テスト駆動開発(TDD)ハンズオンのすすめ - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは、あるいはこんばんは。すぱ..すぱらしいサーバサイドのエンジニアの(@taclose)です☆ 弊社では先日テスト駆動開発（以降、TDDと呼ぶ)ハンズオン勉強会を開催しました！ 今回の記事の内容はズバリ２つ 誤解してる!?テスト駆動開発の良さ！学ぶ事の意味！ TDDハンズオン勉強会を開催する意図や実施内容、感想！ 読者のターゲットは TDDを誤解している人 TDDハンズオン勉強会を弊社でもやろう！とか思ってる人 を想定していますっ。 誤解されがちなTDD、記事にするには書ききれないTDD...なるべく小難しい内容は省いて興味を持ってもらうための記事を書いてみようと思います！ テスト駆動開発（TDD）は良い物だ！ テスト駆動開発（TDD）とは何か？ TDDに対する誤解 TDDハンズオンについて TDDハンズオンの趣旨 TDDハンズオンの計画 事前準備 スケジュールと概要 TDDハンズ
こんにちは。ホクソエム支援部サポーターのPython担当、藤岡です。 最近はデータエンジニア見習いとしてBI周りを触っています。 今回はpytestのfixtureについての記事です。 pytest自体が有名で記事もたくさんあるので、今回は地味だけど重要だと個人的に思っている usefixturesとスコープについて取り上げます。 地味とはいえ、pytestの初心者がfixtureを使いこなすためのステップアップに必要な内容だと思います。 ぜひマスターしていただければ幸いです。 1. 前書き 基礎的なことに関してはこの記事にとても簡潔にまとまっているので、こちらをまず読むのがオススメです。とても良い記事です。 pytestは独自の書き方を持ち込んでいるライブラリです。その機能を使いこなすと「綺麗」なコードにはなりますが、反面それは使われている機能を知らない人にとってはこの上なく読みにくいも
PHP Conference Japan 2021での発表資料です https://fortee.jp/phpcon-2021/proposal/3ed8a69b-8618-4644-9a8c-655505078743
第17回Quesにて「Agile Testingを夢見たテスト自動化」というタイトルで登壇、テスト自動化のしくじりについて話しました - BASEプロダクトチームブログ
こんにちは。BASE BANK 株式会社 Dev Division にて、Engineering Manager をしている東口（@hgsgtk）です。 TL;DR 第 17 回 Ques にて「CI のためのテスト自動化」というテーマでの登壇依頼をいただき「Agile Testing を夢見たテスト自動化 〜ATDD への挑戦から始まる 1 年間の試行錯誤〜」というタイトルで発表しました 実際にうまく行かなかったことも含めてテスト自動化のしくじりを話しました Agile Testing・ATDD/BDD/SBE に興味がある方に参考になる資料を公開しました 第17回Quesとは Ques とは Software 品質保証に関わる QA エンジニアの活性化を目的とした QA 専門イベントです。 ques.connpass.com Software品質保証に関わるQAエンジニアの活性化を目的
リファクタリングという行為自体は好きでしょうか？ A. 好きというかもはやストレス解消 B. 好きなのでノンストレス C. 少しストレス...仕事ならやるけど D. できればやりたくない 業務上の必要性とか、将来の人のためとか、時間の都合とか、報酬の高さとか、そういうのを棚に置いたとして。 ... 新しい機能開発をするのに比べてどうでしょう？ 新しいプログラミング言語やフレームワークを使うのに比べてどうでしょう？ 置き去りのリファクタリングチケット とある風景... seaさん「動いたけど、リファクタリングしたいね」 landさん「でも今は無理だな」 seaさん「チケットだけおいて作って後でやろう」 landさん「うん、そうしようー！」 (...1年後、まだ忙しい) seaさん「いつかやりたいねー」 landさん「いつかやりたいねー」 (...2年後、平和になった) seaさん「早く帰ろう
#yapcjapan YAPC::Kyoto 2023に行ってきた・喋ってきた - その手の平は尻もつかめるさ
yapcjapan.org 2023年3月19日に開催されたYAPC::Kyoto 2023に参加してきました。もう2週間も前の話になるんですね......USに戻ってきてから色々あり、すっかりブログを書くのが遅くなってしまいました。 YAPC::Kyotoの様々な感想については「にゃんこ酒場.fm」で id:papix、id:karupanerura さんら運営の方々と喋ったPodcastが公開されているので是非お聴きくださいませ！ nyanco-sakaba-fm.hatenablog.com 面白かったトーク ジョブキューシステムFireworqのアーキテクチャ設計と運用時のベストプラクティス id:tarao さんの発表。Fireworqが発表されたあたりって、スケーラビリティが高くなおかつ複数の言語から良い感じで使えるジョブキューのプロダクトについて「何使えば良いんだろうねえ」っ
目的 先日、GitHub Copilotに関するオンラインセミナーを受けていたところ 「GitHub Copilotは、エディタ上で開かれているソースの内容も考慮してソースを推論する」という特徴を聞きました。 ふと、 「テストコードさえ書いたらその要件を満たすコードを勝手に生成してくれるのでは、、、？ なんて興味が湧いたので検証してみようと思います。 もし、期待通りになったらTDDが今後さらに熱を帯びるのではないでしょうか。 使用言語: python テストフレームワーク: pytest まずは簡単なコードで試す 関数名から推論されないように無機質な名前にしています。 class Functions: def function(a ,b): return a + b class TestClass: def test_function1(self): assert Functions.fu
E2E自動テスト導入・運用をめぐる先入観と実際に起きたこと / Preconceptions and What Happened with E2E Testing
Scrum Fest Niigata 2022 https://www.scrumfestniigata.org/
TDDが必要なのはどんな時？新人の質問からテスト駆動開発の理解を深める - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
開発部門（基盤本部）でエンジニアの育成を担当している高玉です。 BIGLOBEでは週に1日、集合型の新人エンジニア研修を開催しています。インターネットに公開された教育コンテンツを活用しながら、手を動かして学ぶ（Learn by doing）が特長です。 style.biglobe.co.jp 研修の後に必ずアンケートに回答してもらっているのですが、新人ならではの質問をもらえるのがいつも楽しみです。 さて、テスト駆動開発（Test Driven Development：TDD）について学んだ後にもらったのが、次の質問です。 Q 仕様がコロコロ変わるケースや、コードを触りながらわかっていくような非機能要件などには適用できなさそうだと思いました。どういったケースにTDDが用いられるのでしょうか。逆にどういったケースには向かないのでしょうか？ 研修の様子をお伝えするために、この質問にどう回答したの
Lessons from Writing a Compiler
The prototypical compilers textbook is: 600 pages on parsing theory. Three pages of type-checking a first-order type system like C. Zero pages on storing and checking the correctness of declarations (the “symbol table”). Zero pages on the compilation model, and efficiently implementing separate compilation. 450 pages on optimization and code generation. The standard academic literature is most use
こんにちは、Androidチームの田熊（fgfgtkm）と外山（sumio）です。SWETのAndroidチームでは、Androidのプロダクトに対して自動テストのサポートをしています。 この度株式会社Mobility Technologiesが提供するタクシーアプリ「GO」のAndroid版に対する、おおよそ2年間に渡る取り組みが終了しました。 本記事では、この取り組みで行ってきた次の2点を紹介したいと思います。 「GO」のAndorid版に対してどのような自動テストを導入したか 開発チームに自動テストを定着させるまでにやったこと タクシーアプリ「GO」に対しての自動テスト導入 SWETのAndroidチームは「社内のAndroidエンジニアが自動テストを書くことを習慣化している」ことをゴールの1つとして、自動テストを普及させるための取り組みをしています。 その中でAndroidのテスト
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
iOSアプリのメモリリークを発見、改善する技術 - クックパッド開発者ブログ
t_wadaさんによるTDDワークショップを開催しました - Pepabo Tech Portal
Codecov is now open source - Codecov
テストファースト開発: 柴田 芳樹 (Yoshiki Shibata)
自動テストの効果測定に使われるEMTEとは？ - LIFULL Creators Blog
Modern Best Practices for Testing in Java
第9回 自動テストの実行結果 ～意思決定と行動を促す情報としての役割～ | gihyo.jp
114. テスト駆動開発とは何であって、何でなかったのか？ w/ twada | fukabori.fm
1週間リリースを支えるAndroid自動テスト運用 | メルカリエンジニアリング
『継続的デリバリーのソフトウェア工学』...ソフトウェア工学とは何か？ - Magnolia Tech
t_wadaさんによるTDD研修をワードクラウド・名言5選で振り返ってみた - Qiita
第2回 偽陽性と偽陰性 ～自動テストの信頼性をむしばむ現象を理解する～ | gihyo.jp
[msw, Jest, Node.js] mswを利用してHTTP境界のテストを書く
JUnitで学ぶ実践的で本質的なユニットテストの考え方 - Qiita
第8回 脆いテスト ～継続的な変更と改善を阻むテストの原因と対策～ | gihyo.jp
Playwright を使用したエンドツーエンド テストの概要
Playwright連載始まります | フューチャー技術ブログ
TDDで過去と戦った話 - BASEプロダクトチームブログ
twadaさんによる2023年度版TDDワークショップを開催しました - Pepabo Tech Portal
TDDのTips - BASEプロダクトチームブログ
第1回 学習用テスト ～学びを自動テストとして書く～ | gihyo.jp
pytest fixtureの地味だけど重要な部分について - 株式会社ホクソエムのブログ
#phpcon2021 ステップ実行だけじゃないXdebug / hello-xdebug
リファクタリングという行為が好きか？ - jfluteの日記
AIコードジェネレーターとTDDって親和性高くない、、、？ - Qiita
タクシーアプリ「GO」Android版へ自動テストを導入するまでの道のり - DeNA Testing Blog