タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
テストコードを書き始める前に考えるべきテストの話（2021年版） #scrumosaka / scrum_fest_osaka_2021
以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P12 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf#page=15 ※2011年版は現在リンク切れのため、最新版のシラバスのURLを掲載しています P17 概説テスト分析 http://www.slideshare.net/takashiyamasaki378/ss-55384920 P29 システム/
「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 https://vimeo.com/742517199/e001ac43ac ＜参考リンク＞ Twitter https://twitter.com/jnchito Blog https://blog.jnito.com/ Qiita https://qiita.com/jnchito プロを目指す人のためのRuby入門［改訂2版］ https://gihyo.jp/book/2021/978-4-297-12437-3 Everyday Rails - RSpecによるRailsテスト入門 https://
IDEにChatGPTを統合、「この関数のテストコードはどこ？」「XXXを実装するならどう書けばいい？」など、AIでコードと対話できる「qqbot」登場
IDEにChatGPTを統合、「この関数のテストコードはどこ？」「XXXを実装するならどう書けばいい？」など、AIでコードと対話できる「qqbot」登場 テキストから高度なイラストを生成するAIや、人間と自然な対話を可能にするAIが最近話題になっています。 この人間と自然な会話をするAIチャットの代表的なサービスであるChatGPTの派生サービス（Variant of ChatGPT）をVisual Studio CodeなどのIDEに統合し、開発中のコードについて「この関数のテストコードはどこ？」などと対話できる「qqbot」が登場しました。 開発したのはDan Robinson氏。 Introducing qqbot, a variant of ChatGPT that lives in your IDE. The cool thing about qqbot is that it k
リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～で発表した資料です。 【発表資料中のURL】 ※複数ページで出てくる場合は、初出のページ数に掲載 ◆P7 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 ◆P17 リーダブルテストコード / #vstat ◆P43 見てわかるテスト駆動開発 ◆P46 JaSSTレポート（過去のJaSSTの講演資料などが載っています） ◆P47 Agile Testing Condensed Japanese Edition ◆P48 A Practical Guide to Testing in DevOps Japanese Edition ◆P49 The BDD Books - Discovery (Japa
「テストコードを書く？書かない？」ソフトウェアテストのいろんな疑問をテストのプロに聞いてみた - エンジニアHub｜Webエンジニアのキャリアを考える！
「テストコードを書く？書かない？」ソフトウェアテストのいろんな疑問をテストのプロに聞いてみた ソフトウェアテストはソフトの品質を高めるためには、欠かせない工程です。では、テスト・品質保証のプロたちは、どんなことに気をつけて、ソフトウェアテストを実践しているのでしょうか。仕様やスケジュール、テストの設計まで、テストにまつわる疑問を、ソフトウェアの品質保証・テストに特化した企業、SHIFT社のお二人にぶつけてみました。 ソフトウェアへのバグの混入を防ぎ、ソフトウェアの品質を高めるためにはテストの工程が不可欠であり、「どうすれば良いテストを実施できるか」というノウハウもまた非常に重要です。では、テストを突き詰めて追求する、スペシャリストのノウハウとは。 今回はソフトウェアの品質保証・テストに特化した企業であり、テストを前提としたアジャイル体制構築のコンサルティングにも専門性を持つ、株式会社SHI
なぜテストを書くの？（または書かないの？） 〜テストコードの7つの役割〜 / #tamarubykaigi01
Tama Ruby会議01のキーノートとして発表したスライドです。 https://tama-rb.github.io/tamarubykaigi01/ 参加レポートはこちら。 https://blog.jnito.com/entry/2019/07/07/102734
導入 どうやら新卒2年目社員のAさんが上司のZさんにプロジェクトにおいてテストコード導入を打診してるようです。少し内容を見てみましょうか。 Aさん(新卒2年目社員)「最近テスト自動化やテストコード、TDDなどの単語をよく聞きます。うちはテストコード書いてないですし、実装後の簡単な動作確認、最終の結合テストしかしていません。開発体験と品質を上げるために、テストコードを導入したいです。」 Zさん(上司)「そうは言うがね、君。今のうちの状況を見てごらんよ。みんな複数のプロジェクトに関わっていて、常に多忙。残業時間もぎりぎりで何とかプロジェクトが回っている状態だよ。そんなみんなにさらに作業を増やすようなことを提案するというのかね？しかも、テストコードはお客様からしたら作っても作らなくても関係ない、いわば直接利益に関係ないような作業じゃないか。もちろん、世の中で認知されているということは知ってるよ？
テストコードを書き始める前に考えるべきテストの話 #DevSumi / Developers_Summit_2020
以下のイベントの投影資料です。 https://event.shoeisha.jp/devsumi/20200213/session/2364/ 発表時の諸注意など http://nihonbuson.hatenadiary.jp/entry/2020/01/31/090000 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P2 Agile Testing Fellow https://agiletestingfellow.com/ P15 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf P20 概説テスト分析 http://ww
はじめに この記事は、Merpay Tech Openness Month 2023 15日目の記事です。 こんにちは。メルペイ加盟店精算チームのバックエンドエンジニア@r_yamaokaです。 今日は現在自分がリードして取り組んでいるテストコードの改善について紹介したいと思います。 抱えている課題 私が所属している加盟店精算チームのマイクロサービスは加盟店さま向けサービスとして欠かせないものであり、メルペイ最初期から存在するサービスです。他のマイクロサービスにあまり無い特徴として多数のバッチ処理を行っている点が挙げられます。 お客さま（メルペイユーザー）がお店で行った決済は、一定の頻度で集計し決済手数料を差し引いた上で加盟店さまの銀行口座へ振り込むことになります。 最終的な振込金額を算出するまでの流れとしては 個々の決済金額のリコンサイル（会計マイクロサービスとの金額照合） 日次集計 締
Sansanは10月25日、テストコードについての研修資料を無料公開した。4月に実施した新卒の技術研修で使った資料の一部で、入社2年目の社員が作成。Pythonのテストフレームワーク「pytest」でのテストコードの書き方や、VSCodeでのテスト方法などを解説している。 同社はテストコードの便利な点として「実行確認しやすい」「リファクタリングや修正後に実行結果や振る舞いが変わっていないことを確認できる」「コードの挙動が理解しやすい」を挙げる。テストコードの重要性を理解し、テストコードを活用できるようになることを目的に研修を行ったとしている。 関連記事 新卒向け「統計学の基礎」100ページ超 SaaS企業が無料で資料公開 ブレインパッドが、新卒研修で使った統計学の学習資料を公開した。統計学の基礎を解説したもので、ページ数は100ページ超。スライド公開サービス「Speakerdeck」から無
こんにちは。決済チームでエンジニアとして働いている芦川です。 UPSIDER Tech blog 第2弾として「決済チームがテストコードを書く際に気をつけていること」を紹介しようと思います。 TL;DR 100％のテストカバレッジを目指す テストはブラックボックスを優先して記述、どうしても到達できない場合はホワイトボックス 最初のテストケースは、テスト対象が動作する最も一般的なケースであるべき 私たちは日々大量のコードを書いており、そのシチュエーションは多岐にわたります。 そういった環境において、動作確認からのコード改修のコストを考えた場合、自動テストの有無によって生産性に大きく差が出ることは容易に想像ができます。また、既存のサービスに改修を加えるために、そのサービスの概要を把握したい場合、良いテストコードはドキュメントとして役立ちます。 以前、私はテストコードを一切書かないプロダクトの開
テストコードが増えるとバグは減るのだろうか？ / Does more test code mean fewer bugs? - Speaker Deck
Transcript ςετίʔυ͕૿͑ΔͱόάݮΔͷͩΖ͏͔ʁ�� ʮ���ˠ������ʯͰݟ͑ͨੈքͷ� גࣜձࣾ;0;0ςΫϊϩδʔζ� ;0;0508/෦�J04νʔϜ� ໊औ�߂ฏ Copyright © ZOZO Technologies, Inc. © ZOZO Technologies, Inc. גࣜձࣾ;0;0ςΫϊϩδʔζ� ;0;0508/෦� J04νʔϜ ໊औ�߂ฏ 20192݄ΑΓݱ৬ɻ ZOZOTOWN iOSΞϓϦͷ։ൃΛ͍ͯ͠·͢ɻ झຯͰݸਓ։ൃɻ 2 © ZOZO Technologies, Inc. 3 ���ˠ������ ʹ ͜ͷ�΄ͲͰ૿Ճͨ͠ςετΧόϨοδͷׂ߹ © ZOZO Technologies, Inc. 4 ���ˠ������ ����� ˞ܭଌର͜ͷ�ͷ։ൃͰؔ༩ͨ͠ϑΝΠϧʹߜ͍ͬͯΔ © ZOZO Te
フロントエンドのテストコードを書くときに大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームの @mugi_unoです！ kintone では フロントエンドの刷新プロジェクト（通称フロリア）が進行中です。 blog.cybozu.io kintone の開発では E2E 主体の自動テストを整備していましたが、 フロントエンドの刷新に合わせて、新たにフロントエンド側でのテストコードを積極的に書いています。 テストを書くことに不慣れなメンバーもいるため、日々 Pull Request 上でのレビューやペア・モブ作業を通じて、知見の共有が行われています。今回はフロントエンド刷新のテストを書いてきた中から、筆者が有用だと感じた知見やノウハウを紹介したいと思います。 目次 💡「実はそれ最初からパスしてるかもしれない」 期待する操作で期待する結果になることを厳密に検証する 他のテストケースによって前提条件を担保する 💡「テストコード上のロジッ
過度なDRYは読みやすさの敵！？「リーダブルテストコード」という発表をしました #vstat - give IT a try
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
作ったものが想定した動作をしているか。 それを確認するために、テスト（試験）を行います。 検証したいことがちゃんと実現できて確認が取れているのであれば、その品質自体は割と気にされないことが多い印象です。 保守・運用・追加開発 をしていくプロジェクトが多くあると思います。 その作業の中で、改善を取り入れていくこともあると思いますが、その中でも一番後回しにされるのが、テストコードの改善のように思います。 推測ですが、「コストによるメリット・リターンが少なすぎる」ことが理由かな…と（開発者目線ではリターンが大きいのですが、運用者目線ですとリターンが少なく見えてしまう）。 であれば、最初からある程度綺麗なものがどういうものかを考え、作成しておけば良いのではないか・・！ ということで、考察していきたいと思います。 前提 考察をするにあたり、言語化した時の表現や意味のズレが発生しやすい部分もあると思い
「テストコードにはテストの意図を込めよう」の発表報告＆補足説明＆質問回答 #vstat - ブロッコリーのブログ
先日、「リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～」というイベントで登壇してきました。 veriserve-event.connpass.com 今回は発表内容に対する補足と、発表に対していただいた質問に回答します。気になるところだけでも読んでもらえればと思います。 目次 目次 発表内容 発表に対する補足 【補足1】都道府県のテストについて 【補足2】Parameterized Testsへの利用について いただいた質問の回答 【質問1】リーダブルなテストコードの勉強方法はありますか？ 【質問2】テストコードのメンテナンスをするにあたってのリファクタリングの頻度はどれくらいか？ 【質問3】レビューをする際、機能自体のレビューにかけた時間に対してテストのレビューにかける時間はどのくらいの割合で行っていますか? 【質問4】
TypeScriptでテストコードを徹底的に型推論する / TypeScript Meetup 4
2020年6月16日 TypeScript Meetup #4 にて発表した資料です。
株式会社ラクスが開催するエンジニア向けのイベント「RAKUS Meetup」。今回は「SaaS新規プロダクトの技術」をテーマに、同社プロダクト「楽楽労務」の開発を担当する福岡憲治氏が登壇し、「新規プロダクトの開発速度と品質の両立を支える自動テスト」という内容で話をしました。 新規プロダクトならではの悩み 福岡憲治氏（以下、福岡）：それでは『新規プロダクトの開発速度と品質の両立を支える自動テスト』というタイトルで福岡が発表いたします。お願いします。 ではいきなりですが、まずはじめに、新規プロダクトとタイトルに入っているとおり、新規プロダクトならではの悩みについて、簡単にお話しできればと思います。 まず1つ目、ドメインに対する理解が不十分だったり、アジャイルに機能開発していくので、作り直しが発生します。あるいは、新規プロダクトである程度できあがってくると、チームメンバーを増員することになります
リーダブルテストコード - Qiita
はじめに よく言われるように、ソースコードというものは書かれることよりも読まれることの方が多く、それゆえ読みやすいコードを書くということが非常に重要です。それはテストコードにおいても同様であり、プロダクトコードと同等に資産として扱う必要があります。 テストコードは具体的な値を用いて記述し、また複数の変数の値の組み合わせでテストケースを起こすため、プロダクトコードと比べて冗長になりがちです。 書籍『リーダブルコード』の14章でもテストコードの読みやすさについて触れられていますが、本稿では読みづらいテストコードをリファクタリングして読みやすくするためのテクニックを紹介したいと思います。 なおサンプルコードはJavaScriptで記述されており、そのテストコードはJest1を用いて書いています。 ソースコードはGitHubにあります。 リファクタリング(その壱) 以下の、決して読みやすいとはいえ
2023年 研究開発部 新卒技術研修 ~ テストコード編 ~ - Sansan Tech Blog
こんにちは、研究開発部 Data Analysisグループの笛木です。 4/26（水）〜 4/28（金）で研究開発部内の技術研修を行いました。 こちらのブログの続きでテストコードについての研修資料を一部公開します。研修では新卒2年目の私が1年間で部内のコードなどから学んだ情報を共有しました。至らない部分もあるかもしれませんが、ご参考になれば幸いです。 こちらの研修で使用したGitHubのコードリンクは以下です。適宜、ご参照ください。 github.com 目次 目次 はじめに この研修の目的 研修スコープ外 テストコードについて テストコードの便利な点 テストコードの悪い例 テストコードに関するFAQ pytestによるテストコードの書き方 ファイル名 ディレクトリ 基本編 Parametrize Fixture 異常系 Mock indirect conftest 知っておくと活用する場
こんにちは、NewsPicksの北見です。 ところで皆様、テストコードって書いてますか...? ネットでテストコードについて検索すると 「テストコードを書きましょう」 「テストコードとはこうあるべし」 「TDD(Test Driven Development)だ」 等々が叫ばれています。 ただ、なんとなく「方法論ありきでとにかくテストを書け」と言われているようで、テストの必要性について納得感に欠けている方もいらっしゃるのではないでしょうか? なぜ テストコードを書くのでしょうか? テストコードを書く理由 将来リファクタリングをしやすくする テストコード書く途中で、開発者自身が仕様を理解し、成長できる 最後に テストコードを書く理由 諸説ありますが、私が思うテストコードを書く理由は 将来リファクタリングをしやすくする テストコード書く途中で、開発者自身が仕様を理解し、成長できる の2つです。
まえがき 世間ではテストをしないこと/テストを書かないことを悪とするみたいな文化が定着してきたのか、テストを書かない開発というのが減ってきてると思います。 では「正しくテストを書けているか」「テストを書く文化を生かしているか」というとどうでしょう？ これらの問いに答えられずテストを書くことをゴールにして満足していると、それは宝の持ち腐れならぬテストコードの持ち腐れとなります。 執筆のモチベーション この記事を印刷して札束のごとくビンタするのが目的です。 以下に該当すること”だけ”を考えているような場合はビンタされるかもしれません。（絶対ではないですが危ない可能性があります） うちはテスト書いてるから大丈夫！ちゃんと開発工数とは別に単体テスト工数も見積もってるよ！ ちゃんとホワイトボックス的に書いてカバレッジ担保しているからうちはちゃんとテストしてるよ！ コード修正の都度ちゃんとテストコード
はじめに 「研究用のプログラムにもテストコードやドキュメント書いたほうがいいよね。」 「分かっちゃいるけど、そんな面倒なことやってられないよ。」 という研究者あるあるを解決すべく、僕が普段実践している開発スタイルを紹介します。 この開発スタイルのすごいところは： テストやドキュメントを一切書かない場合と比べて 追加の工数がほぼゼロ。 普通にコーディングしているだけで、いつのまにかテストコードとドキュメントまでできあがっている。 実装、コメント、テスト、ドキュメントが自然に同期するので、保守しやすい。 Pythonを例に紹介しますが、コメント内にテストを書けるツールと、コメントからドキュメントを生成できるツールをもつ言語ならばどれにでも応用できるはずです。 この開発スタイルに至った背景 ソフトウェア開発において、テストコードやドキュメントを整備することでプログラムの品質が向上することは広く知
CTOの藤村です。つい最近まで STORES ブランドアプリ のチームでRailsを書いていました。 STORES ブランドアプリ のRailsリポジトリではdatabase_cleanerを（strategy = truncationで）使ってテスト中のデータベースをリセットしており、このことがテストコードの品質、速度などで重荷となっていました。 これを、テスト実行時にテストコード自体を書き換えて改善する仕組みを作り、先日無事Transactional Testへの移行が完了しました。ということで気分がとてもよいので、どうやったか共有させてください。 課題 STORES ブランドアプリのRailsのテストコードは速度に課題がありました。 テストデータを片付ける仕組みとして、 Railsエンジニアにはお馴染みのdatabase_cleanerというGemを使っていました。database_
VS CodeのGo言語テストコード生成ツールを使ってみたらめちゃくちゃ便利だった話とか - kdnakt blog
年末年始はGoのテストコードを書いて過ごしている。 そんなことよりそろそろ2019年の抱負的なものを書かないと……とは思うものの、振り返り系記事ばかりで技術系記事がおろそかになってもあれなので、テストコードを書いていて学んだことをまとめておく。 [Go言語用VS Codeセットアップ手順] [テストコード・スケルトン自動生成] [関数の戻り値を比較する3つの方法] 等価演算子 (==, !=) で比較する Object.Equal() で比較する リフレクションを利用して reflect.DeepEqual() で比較する [まとめ] [Go言語用VS Codeセットアップ手順] 実行環境はMac 10.14.2 + VS Code 1.30.1。 VS Codeの左側のメニューの5番目の四角いアイコンが「Extensions」、拡張機能のメニュー。検索ウィンドウに「go」と入力するとMi
さまざまなテストレベルとロールで活躍されている方々がテストコードをリーダブルにする方法について語り、それぞれの違いや共通点について議論する、「リーダブルなテストコードについて考えよう」。ここで株式会社ソニックガーデンの伊藤氏が登壇。リーダブルなテストコードとは何か、リーダブルなテストコードを書くための具体的な意識を紹介します。 伊藤氏の自己紹介 伊藤淳一氏：リーダブルコードという発表です。いきなり余談から入りますが、今日仕事をしていたらテストコードに助けられました。 仕様変更がいつ入ったのかを調べなきゃいけなくなってコミットを追いかけていったら、過去の僕がすごくわかりやすいテストコードを書いていて、仕様Aを仕様Bに変えることがdiffを見れば一目瞭然というようなものを作っていました。リーダブルなテストコードを書いてて良かったと思った日がこの勉強会の開催日で、ナイスタイミングだと思いました。
XUnit Test Patterns に筆者の経験則を落とし込んでまとめています。 2024/01/25 TechBrew in 東京 〜技術的負債と共に歩むプロダクトの成長〜 の登壇資料です。 https://findy.connpass.com/event/306451/
サバンナ便り ～ソフトウェア開発の荒野を生き抜く～ 第7回テストコードの認知負荷 ～テストの名前、構造、情報量を工夫する～ 開発の現場では、既存のテストコードから仕様を読み解く機会がよく訪れます。そのようなとき、テスト対象の仕様やテストの意図を読み解きやすいテストとそうではないテストがあることに気付きます。今回はテストコードの読み解きやすさに寄与する要素を考えます。 認知資源と認知負荷 人間は何かを読み解くときに脳のリソース（脳内のワーキングメモリ）を使います。リソースの量は有限で、個人差があります。このような脳のリソースは「認知資源」と呼ばれています。 人間が何かを読み解くときに認知資源が何にどのくらい割かれているかという概念を「認知負荷」と言います。「どのくらい」は状況に左右されます。たとえば、読み解く対象を知っているかどうかで認知資源が割かれる量は変化します。「何に」も状
テストコード内では条件分岐を書かないようにする
テストコード内では条件分岐を書かないようにする 2023.01.21 誰でも読める愚直なコードであることの 1 つの目安として、テストコードの中に if 文や三項演算子などの条件分岐が入り込んでいていないことが上げられます。if 文が存在するコードはアンチパターンであるといえます。実際に if 文がテストコードの中に入り込んだ例を見てみましょう。 テストコードは誰でも読める愚直なコードであることが求められます。テストコードにはある種のドキュメントのような、コードの仕様を説明する役割が求められているためです。テストの期待結果が変数になっていて、定義元までジャンプしないと値を確認できないだとか、条件分岐やループが入り込んでいて複雑性が上がっている状態ですと、素直に読みやすいとは言えません。 コードの中では重複排除をするためにさまざまなテクニックを駆使することがありますが、これは単にテストコード
「アプリケーションが壊れているのに検知できないテストコード」を書かないようにするための、べからず集 - Qiita
はじめに テストコードを書くことは重要です。 テストコードがないアプリケーションよりもテストコードがあるアプリケーションの方が望ましいことは間違いありません。 ですが、テストコードも書き方を間違えると、アプリケーションが壊れているのに正しく検知できないテストを書いてしまう可能性があります。 この記事ではそんな「アプリケーションが壊れているのに正しく検知できないテスト」のコード例を「〜するべからず（〜してはいけない）」の形式で紹介し、その修正方法を説明していきます。 サンプルコードはRSpecで書いてます（でも他の言語でも考え方は同じはず） サンプルコードはRailsアプリケーションをRSpecでテストする場合を想定したものになっていますが、基本的な考え方自体は他の言語やテスティングフレームワークでも適用可能なはずです。 RSpecのイロハについて先に学んでおきたいかたは「使えるRSpec入
概要 プロダクト開発を行う上で、テストコードは重要な要素であるかと思います。 ユニットテストコードを書くことで、クラス単位の動作保証を行うことが出来ます。また、E2Eテストやインテグレーションテストを書くことで、DBアクセスや外部連携を含めた、プロダクトにおける一気通貫の動作を確認することが可能になります。 作成したテストコードは、CICDと組み合わせて、自動テストとして定期的に実行させます。これにより、既存のソースコードを変更した際の品質を (ある一定レベルにおいてですが) 担保することが出来るようになります。結果として、開発メンバーは積極的なリファクタリングを行えるようになり、健全な開発のライフサイクルが回る・・・という流れになります。 テストコードも、プロダクションコードと同様に、継続的に保守・開発していく必要があり、一定のお作法に則って開発していく必要があります。無秩序で設計が不十
学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。 『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『Engineers in VOYAGE』（ラムダノート、2020）編者。テストライブラリ power-assert-js 作者。
テストコードがコードの冗長化であるという話に、腑に落ちないという指摘がちらほらあるので、どういうことかを解説してみます。 このエントリについてです。 テストというのは、ソースコードの冗長化だと思う - きしだのHatena ※ ここでの冗長化は、英語版Wikipediaでいう「Information redundancy, such as error detection and correction methods」のことですね。 まず、「これは冗長化だな」と納得してもらいやすそうな例として、間違いが絶対に許されないような計算をするシステムの実装を考えてみます。 このような場合に、同じ仕様を3つの組織に渡して独立に実装をしてもらい、計算が必要になったとき3つのモジュールを呼び出して多数決で結果を返すようにします。 このようにして正確さを担保するのは、冗長化と呼べると思います。 そして、これ
リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～ 2022-07-27 での講演スライドです。
【Golang】VSCodeで自動生成されるテストコードをカスタマイズする - magamingのブログ
こんにちは。Goのテスト、書いていますか？ 私はめちゃめちゃ書いています。 VSCodeに拡張機能(vscode-go)を入れることで、テストコードを自動生成することができることを最近知ったのですが、これがとても便利です。 使い方は以下の記事でまとめられています。 kdnakt.hatenablog.com これはめちゃめちゃ便利なのですが、デフォルトだと少し物足ないところがあったので、カスタムテンプレートを作成しました。 GitHub - Magaming/gotests-templates vscode-goは内部でgotestsを使っているので、それ用のテンプレートを用意している形です。 具体的には次のようなことをしています。 go-cmpを使う 標準だと reflect.DeepEqualで比較しているが、これだとtime.Time型を含んだ構造体の比較とかで死ぬ go-cmpは、
CircleCI、テストコードをAIで自動生成してくれるPonicodeを買収、CircleCIに統合へ CircleCIは、AIによるテストコードの自動生成や、コード分析による品質管理などのツールを提供するフランスのスタートアップ「Ponicode」の買収を発表しました。 CircleCIに統合することで、高い品質のコードを迅速かつ容易に生成できるようになるとしています。 Welcome to the CircleCI family, @PonicodeDev! How acquiring Ponicode furthers our mission to provide the best CI/CD tooling available and enable software teams to innovate faster with its powerful #AI engine: ht
PHPerKaigi 2024 https://fortee.jp/phperkaigi-2024/proposal/1be00d06-afa8-4ba9-a49b-9118c782f8e3
IDEにChatGPTを統合 「この関数のテストコードはどこ？」「○○を実装するならどう書けばいい？」など、AIでコードと対話できる「qqbot」登場
IDEにChatGPTを統合 「この関数のテストコードはどこ？」「○○を実装するならどう書けばいい？」など、AIでコードと対話できる「qqbot」登場 ChatGPTを「Visual Studio Code」などのIDEに統合し、開発中のコードについて「この関数のテストコードはどこ？」などと対話できる「qqbot」が登場。トライアルの申し込みを受け付けている。 テキストから高度なイラストを生成するAIや、人間と自然な対話を可能にするAIが最近話題になっています。 この人間と自然な会話をするAIチャットの代表的なサービスである「ChatGPT」の派生サービス（Variant of ChatGPT）を「Visual Studio Code」などのIDEに統合し、開発中のコードについて「この関数のテストコードはどこ？」などと対話できる「qqbot」が登場しました。 開発したのはDan Robin
AIとのペアプロへまた一歩前進、「GitHub Copilot」登場。AIがコメントからコード生成、書きかけのコードを補完、コードを見てテストコード自動生成など
GitHubは、AIがまるでペアプログラミングの相手の様に、コメントの説明からコードを生成してくれたり、実装されたコードを基にテストコードを生成してくれる機能などを提供する新サービス「GitHub Copilot」のテクニカルプレビューを発表しました。 Meet GitHub Copilot - your AI pair programmer. https://t.co/eWPueAXTFt pic.twitter.com/NPua5K2vFS — GitHub (@github) June 29, 2021 マイクロソフトは5月に、自然言語（英語）で説明すると自動的にその内容をプログラミング言語の「Power Fx」に変換してくれる機能をローコード／ノーコードツールの「Power Apps」に搭載すると発表したばかり。 参考：［速報］マイクロソフト、自然言語をプログラミング言語にAIで変
Tama Ruby会議01で「テストコードの役割」について発表してきました #tamarubykaigi01 - give IT a try
はじめに 2019年7月6日、渋谷のGMO Yoursさんで開催されたTama Ruby会議01で「なぜテストを書くの？（または書かないの？） 〜テストコードの7つの役割〜」という発表をしてきました。 スライドはこちらです。 このエントリではこの発表の紹介やイベントの感想を書いていきます。 この発表テーマを選んだ経緯 スライドの9枚目にも書いたとおり、もともとは「RSpecを題材にしたテックな話を」とお願いされていました。 しかし、ネットなどを見ていると、「テストって難しい」「RSpecがわからん」と言っているプログラミング初心者さんたちは、テストについて何か根本的な思い違いをしているんじゃないか？という漠然とした疑問や懸念を僕は持っていました。 テストにおける「土台となる考え方」を会場のみなさんと共有したかった そういう状態でRSpecのテクニック的な話をしてもどこか歯車がかみ合わないと
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リーダブルテストコード / #vstat
テストコードにはテストの意図を込めよう #vstat
![エリートの、エリートによる、エリートのための“反民主主義”――とその解毒薬 | p2ptk[.]org](https://cdn-ak-scissors.b.st-hatena.com/image/square/a6372461faa955f5542d8de3768208198e687392/height=288;version=1;width=512/https%3A%2F%2Fp2ptk.org%2Fwp-content%2Fuploads%2F2024%2F05%2Fscientific-deliberation.jpg)
テストコード導入奮闘記～私はこうやってプロジェクトにテストコードを導入しました～ - Qiita
テストコードの改革を進めている話 | メルカリエンジニアリング
新卒向け「テストコード」の研修資料 Sansanが無料公開 Python上でのテスト方法を解説
決済チームがテストコードを書く際に気を付けていること - UPSIDER Techblog
【考察】テストコードのきれいな書き方 - Qiita
“テストコードを書く文化”をどう形成していったか 開発速度と品質の両立を支える3つの「自動テスト」とは
なぜテストコードを書くのだろう? - Uzabase for Engineers
テストコードをただ書くだけで満足している人々をこの記事でビンタしたい - Qiita
忙しい研究者のためのテストコードとドキュメントの書き方 - Qiita
RSpecのテストコードを実行時に書き換えて実行速度を改善した話 - STORES Product Blog
過度なDRYを行わず、APIドキュメントだと思って書く 脳内メモリを消費させない“リーダブルなテストコード”の書き方
テストコードを負債化させない上手な付き合い方 / Test Code Management
第7回 テストコードの認知負荷 ～テストの名前、構造、情報量を工夫する～ | gihyo.jp
技術的負債とならないテストコードを書くために考えること - Qiita
テストコードのリファクタリングが目指すもの/DXD 2021
テストコードがコードの冗長化であることについて - きしだのHatena
コンテキストとセマンティクスを意識してリーダブルなE2Eテストコードを書こう
CircleCI、テストコードをAIで自動生成してくれるPonicodeを買収、CircleCIに統合へ
読みやすいテストコードへの一歩、適切なAssertionを使う
gigazine.net
nyan.momo.punyu.jp
search.yahoo.co.jp
godmeetsfashion.com
godmeetsfashion.com
tabelog.com