こんにちは！sakasegawaです！ ( https://twitter.com/gyakuse ) 今日は今流行のChatGPTについて紹介します！ ChatGPTとは OpenAIが開発するGPT-3(※)というめちゃくちゃすごい言語モデルをベースとしたチャットアプリです。 色んな質問にすぐ答えてくれます。 この記事ではさまざまな使い方を紹介します。 https://chat.openai.com/ ちなみにGPT-3関連では、noteの以下記事も便利なのでぜひ読んでみてください AIがコミットメッセージ自動生成！神ツール『auto-commit』『commit-autosuggestions』の紹介 ※正確にはGPT-3.5シリーズと呼ばれています ChatGPTの仕組みを考えながらプロンプトを作る手法はこちらに別途まとめています 文章 質問-応答 〜について教えて Wikiped
「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 - エンジニアHub｜Webエンジニアのキャリアを考える！
「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 単体テストの定義から手法、未来の展望までを、日本におけるソフトウェアテストの第一人者・高橋寿一さんが解説します。 ソフトウェアのテストにおいて、最初のフェーズである単体テスト。若手Webエンジニアの中には、いきなり単体テストを任されて戸惑った方もいるでしょう。仕方なく現場で踏襲されているやり方に従っているだけ、ということもあるのではないでしょうか？ 今回は、単体テストの定義から手法、未来の展望までを、日本におけるソフトウェアテストの第一人者・高橋寿一さんが解説します。 単体テストとは（各社ばらばらな単体テストの定義を再定義） コードベースの単体テスト 命令網羅（C0カバレッジ） 分岐網羅（C1カバレッジ） よくある（コードベースの）単体テストの間違い 機能単位の単体テスト 例：複雑なソート機能のテス
質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition
質とスピード（2022春版、質疑応答用資料付き）
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
テストの学習へようこそ！ コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このコースでは、ウェブ用のテストの概要と探索について説明します。 このコースで学習する内容は次のとおりです。 テストの基礎 自動テストと手動テスト テストを実施する場所と方法 ベスト プラクティス 何をテストすべきか、誰に責任があるのか、目的そのものとしてではなく、目的を達成するために手段をテストすることを検討する方法など、テストの理念。 このコースには、学習に役立つ簡潔で実用的なサンプルコードも含まれています。 コースのスコープには、Node.js などの環境で実行される、フロントエンドの JavaScript とドキュメント モデル、バックエンドでのライブラリ テストが含まれます。テストの経験はありませんが、JavaScript の基礎知識と Node.js などに関する経験が必
追記 2022/11/12 追記 この記事読んで、DI 便利だなって思ったらこちらも併せて読んでみてください。クリーンアーキテクチャーの開設の中で依存性逆転の説明が出てきます。難しいかもしれませんが、一度理解すればつぶしが効く考え方なので腰を据えて読んでみてください。 本文 ここでは、最近のそこそこの規模のアプリだと大体使われてる（と私は思ってる）Dependency Injection（DI）について、何故使ってるのか？というのを私の理解で書いていきたいと思います。 今回の対象言語は C# ですが、DI 使ってる言語であれば大体同じ事情なのかなと思います。 単体テストしたいよね アプリケーションを作るとうまく動いているかテストをすると思います。 たとえ、そのアプリがハローワールドだとしても動かして目視で確認してると思います。 もうちょっとアプリの規模が大きくなってくるとクラス単位やクラス
ユニットテストをGitHub CopilotとChatGPT使って書いてみたらやばかったです | DevelopersIO
GitHub Copilotとの単体テストがやばい。ChatGPTが書いてくれるテストもすごい。もうこれらがない時代には戻れないような気がします。 こんにちは。AWS事業本部コンサルティング部に所属している今泉（@bun76235104）です。 みなさんユニットテスト書いてますか？ 昨今AIがダミーデータを書いてくれたり、ユニットテストそのものを書いてくれたりと技術の進歩がすごいですね。 私はリファクタリングが好きですが、リファクタリングをする前に絶対に必要なもの。 そうテストですね。 今回私がテストを後回しにしてしまった以下のOSSについてGitHub CopilotとChatGPTのそれぞれの力を借りながら、テストを書いてみました ※ これは以前私が始めたプロジェクトであり、OSSとして公開されているので学習に使われても問題のないコードです。 なお、GitHub Copilotの料金や
動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
Software Design連載 2021年9月号 「テストが無い」からの脱却 - MonotaRO Tech Blog
こんにちは、鈴木です。 「テストが無い」状態を脱却しました。 「いつの時代かよ！」と突っ込まれるかもしれませんが、モノタロウは創業から 20 年ほど EC をやっています。昨日書いたコードも、15 年前に書いたコードも、元気にビジネスを支えています。 本記事ではモノタロウの EC を支える API の話をします。「テストが無い」状態がスタートラインでした。そこから、CI を導入して、ローカル開発環境の整備して、テストコードを書いて、リリースマネジメントを導入しました。 目新しいことは書きません。長寿の大規模システムであっても、愚直に数年取り組むことで、「前進できる！」「変えられる！」という実例を書きます。 ※本記事の初出は、 Software Design2021年9月号「Pythonモダン化計画（第2回）」になります。第1回の記事は「Software Design連載 2021年8月号
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう！』 『今までモック使ってたけど意外とモック使わなくても書けるね！』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 前提の話： この記事の本旨は「テスト書きにくいプロダクトコードも依存関係を排除すれば楽にテスト書けるよ」なので、それ設計的にアウトでは？リファクタリング耐性低くない？みたいな話は度外視してます。
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
","naka5":"<!-- BFF501 PC記事下（中⑤企画）パーツ＝1541 --><!--株価検索 中⑤企画-->","naka6":"<!-- BFF486 PC記事下（中⑥デジ編）パーツ＝8826 --><!-- /news/esi/ichikiji/c6/default.htm -->","naka6Sp":"<!-- BFF3053 SP記事下（中⑥デジ編）パーツ＝8826 -->","adcreative72":"<!-- BFF920 広告枠）ADCREATIVE-72 こんな特集も -->\n<!-- Ad BGN -->\n<!-- dfptag ＰＣ誘導枠５行 ★ここから -->\n<div class=\"p_infeed_list_wrapper\" id=\"p_infeed_list1\">\n <div class=\"p_infeed_list\">
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
導入 どうやら新卒2年目社員のAさんが上司のZさんにプロジェクトにおいてテストコード導入を打診してるようです。少し内容を見てみましょうか。 Aさん(新卒2年目社員)「最近テスト自動化やテストコード、TDDなどの単語をよく聞きます。うちはテストコード書いてないですし、実装後の簡単な動作確認、最終の結合テストしかしていません。開発体験と品質を上げるために、テストコードを導入したいです。」 Zさん(上司)「そうは言うがね、君。今のうちの状況を見てごらんよ。みんな複数のプロジェクトに関わっていて、常に多忙。残業時間もぎりぎりで何とかプロジェクトが回っている状態だよ。そんなみんなにさらに作業を増やすようなことを提案するというのかね？しかも、テストコードはお客様からしたら作っても作らなくても関係ない、いわば直接利益に関係ないような作業じゃないか。もちろん、世の中で認知されているということは知ってるよ？
みなさんテストは書いていますよね. 書いていなければふりだしに戻る. 例えば関数 add に対して, 以下のようなテストコードがあるとします. describe("add", () => { it("正しく計算できる", () => { expect(add(1, 2)).toBe(3); }); }); よさそうですね? もしよくないと思うのであればここから下は読まなくても大丈夫なくらい理解している方だと思います. 続いて関数名を変えただけのこちらをどうぞ. describe("sub", () => { it("正しく計算できる", () => { expect(sub(1, 2)).toBe(3); }); }); なんだか明らかに間違っている気がします. もしこのテストが通過してしまったとき我々はどうすればよいのでしょうか. 考えられるパターンは 2 つあります. 実装もテストも正
フロントエンドにおける「単体テストの考え方/使い方」
本稿における「単体テスト」とは自動テストにおける単体テストを指します。手動テストのことではないので、ご了承ください。 単体テストの考え方/使い方という本を読みました。筆者自身、「単体テストはプロダクションコードの付属」という意識がどこかにありました。この本を読んで、単体テストについてあまりに何もわかってなかったことに気付かされ、単体テストの設計はプロダクションコードの設計と同じくらい重要という意識に変わりました。何のために単体テストをやるのか、いいテストとは、「単体」とは、など多くの点で学びを得られ、また、多くのプラクティスとアンチパターンを知ることができました。 本稿はこの本を読んで得られた学びを、フロントエンド開発、特にコンポーネント開発に適用することを試みた際のまとめです。より詳細な解説を求む方には本を手に取ってもらう前提で、できるだけポイントを抑えられるようにまとめることを目指しま
テストコードを書き始める前に考えるべきテストの話 #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
Shizuoka.js #7
はじめに C#は「Windowsでしか開発出来ない言語」などクローズドなイメージから一転し、.NET Coreの誕生によって様々なことが出来るようになりました。最近ではokazukiさんのC# で出来ること一覧が大きな反響を呼び、C#であらゆるアプリが作れることを多くの方に知ってもらえたかと思います。C#のよさを知ってもらうことは嬉しい限りではありますが、他言語をやってきた身としてはC#を取り巻くエコシステムの情報が少ないと感じることが多く、新たに参入される方にとって抵抗があるのも事実だと思います。この記事ではまともなアプリ開発を行うために必要なエコシステムなどご紹介し、C#でも快適に開発出来ることを知ってもらえれば嬉しいです。筆者はWEB開発を主としているので、WEB寄りな話が多くなる可能性がありますがご了承下さい。 「まとも」とは？ タイトルにも書いたまともなアプリ開発とは、一定の品質
Software Design連載 2021年8月号 Python製のレガシー＆大規模システムをどうリファクタリングするか - MonotaRO Tech Blog
Software Design連載開始 ※ (2021/09/02 08:55) 「Pythonを用いて開発を始めたのが2003年」を「Pythonを用いて開発を始めたのが2002年」に修正 こんにちは。金谷です。 このたび、モノタロウにおけるPython大規模開発に関する取り組みを、技術評論社様で発刊されている Software Design に連載させていただくことになりました。 モノタロウがPythonを用いて開発を始めたのが2002年。2021年の現在もPythonを用いた開発が続けられています。 事業の成長に伴い、関連するシステムやエンジニアの数も増え続けていくなかで、いかに安定的に価値を提供し続けられるのか。 モノタロウにおける取り組みを、開発や運用周りを通してご紹介していきます。 本記事の初出は、 Software Design2021年8月号「Pythonモダン化計画（第1
実装例から見る React のテストの書き方 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは！フロントエンドエキスパートチームの@nus3_です。 kintone のフロントエンド刷新プロジェクト（フロリア）では、品質を保ったまま開発を加速させるためにフロントエンドのテストを積極的に行っています。 今回はそんなフロントエンドのテストの実装例をいくつか紹介します。この記事がフロントエンドのテストを行う上での参考になれば幸いです。 テストに使用する主なパッケージ コンポーネントのテスト 補足: Testing Library の記法をチェックしてくれるeslint-plugin-testing-library カスタムフックのテスト 補足: React v18 では @testing-library/react の renderHook を使う 参考リンク 色々なテスト事例 setTimeout を使うコンポーネントのテスト 補足: Storybook の story を使
近日連投していた Next.js 記事のサンプルコードを公開しました。このサンプルコードを元に、私のフロントエンドディレクトリ構成・テスト観点を紹介します（あくまで執筆現在の脳内アウトプットになりますのでご了承ください） フロントエンドディレクトリ構成の事情 タイトルの「フロントエンドディレクトリ構成」をさす「Components」のディレクトリ構成は、いつも悩みのタネです。このモジュールシステムは「デザインシステム観点・アクセシビリティ観点・フロントエンド実装観点」の 3 つの観点が混在するため事情が複雑です。どうせ作るのなら「デザイナー・フロントエンド」どちらの開発基盤にもなりえる、盤石なモジュールシステムを目指したいですよね。 "AtomicDesign やめました"という声をたまに聞くのですが「デザインシステム的に捨てていいの？」と思うこともあるので、とくに要望がなければ、筆者は「
はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか？ 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って
本編開始は 19:05 からです こちらのイベントのYoutubeLive配信のアーカイブです https://tddbc.connpass.com/event/183044/ チャプター 0:00:00 準備開始 0:19:05 講演開始 0:41:55 ライブコーディング開始 0:57:20 プログラミング開始 1:02:00 最初の RED ？ 1:19:00 fake it 1:26:50 最初のリファクタリングおわり 1:36:40 質問タイム 1:51:20 5の倍数に着手 1:53:40 前半のデモのまとめ 1:55:20 質問タイム2回目 1:56:45 リリースから3年後の世界（テストをメンテナンスしやすくする） 2:14:20 テストの構造化とリファクタリングの説明
PHPカンファレンス沖縄2022の登壇資料です。 発表時間の関係で収まりきらなかった内容を大幅に加筆しています。 以下プロポーザルの内容を転記。 ---- テスト書いてますか？ テストを書く理由と実際のテストコードを紹介する実践編に分け、TDD を3年間実践してきた経験に基づいてお話しします。 テストを書いたことのない方が、テストを書いてみたいと思ってもらえることを目指します。 サンプルコードは PHP + PHPUnit ですが、他言語でも通用する考え方を紹介します。 ■ 概要 ・なぜテストコードを書くのか ・レガシーコードとは、テストのないコード ・テストはコストが安いフィードバックループである ■ 実践編 ・テストケースは日本語で書こう ・いろんな assertion を知ろう ・arrange / act / assertion のテストコード実装パターン ・set up / te
PHPerKaigi 2024発表資料 https://fortee.jp/phperkaigi-2024/proposal/f23f927e-2ac8-498e-a047-6376831cbd07
Learn Go with Tests: テスト駆動開発を体験しながら Go を学ぼう - kakakakakku blog
TDD（テスト駆動開発）を体験しながら Go を学べる学習コンテンツ「Learn Go with Tests」を紹介する❗️全てのコンテンツを実施してみて，非常に良かったのでまとめることにした💡 Go に入門できる TDD のサイクル (Red / Green / Refactor) を体験できる コンテンツは "35種類" もある 無料で学べる GitBook (GitHub) に公開されている 日本語対応 英語版 📚 quii.gitbook.io 日本語版 📚 andmorefine.gitbook.io コンテンツ一覧 なんと「35種類」もコンテンツがある❗️ Go fundamentals 🚢 21種類 Install Go（Go をインストールする） Hello, world（Hello, World） Integers（整数） Iteration（反復、繰り返し） A
Wevoxのフロントエンドエンジニアをしているタガミです。最近はmonorepo構成に移行中のWevoxフロントエンドのテストやデザインシステムなどをいい感じにしようとしています。 この記事では、WevoxというSaaSプロダクトのフロントエンドにおける自動テストの話をします。Wevoxはリリースから5年以上が経過し、チームのメンバーも増え、またソースコードも巨大化しています。そんな中でフロントエンドも"式年遷宮"をして、改善を繰り返しています。中にはソースコードをガラッと変えるようなリファクタもあり、担当するエンジニアにとってはデグレの心配が付き纏います。そんな日々変化するフロントエンドを支えるのが自動テストです。 Wevoxの開発チームは決して大人数ではありません。そんなチームでも品質の改善のために一歩ずつ改善しつつある経験をもとに、フロントエンドの自動テストポイントをいくつかお伝えし
クイックサマリー：「テストピラミッド」は、自動テストをUI、サービス、ユニット単位に整理することで、開発に自動テストを組み込む方法を示すために作成されました。2012年に定義されて以降、このモデルは次第に使われなくなってきたように思いますが、本当に廃れてしまったのでしょうか。この記事では、最新のテスト戦略を紹介するとともに、今日のソフトウェア開発におけるテストピラミッドの関連性を検討します。 筆者の同僚であるジャン・フィリップ・ピエトルチェクが、かつてコードを書く開発者の責任について、次のように述べました。 none「我々の仕事の成果を最終的に使用する人々は、（中略）我々がただ最善を尽くすだけでなく、実際に機能するものを作ることを期待しているのです。」 — ジャン・フィリップ・ピエトルチェク 彼の言葉は、私たちが書くコードをそれに依存する人々の観点からとらえている点で非常に印象に残りました
品質やテストといった活動が「本質的にアジャイルになって変わらなければならない」といった問題を定義し、その解決手段を提案する「今、全エンジニアに求められる『アジャイル開発での品質視点の変化』」。ここで株式会社デジタルハーツホールディングスの高橋氏が登壇。最後に、あらためて参加者からの質問に回答します。前回はこちらから。 どうすればうまくリファクタリングができるか 高橋寿一氏（以下、高橋）：じゃあここでもう1回Q&Aタイムを取ります。 高木陽平氏（以下、高木）：ありがとうございます。今Q&Aにまだ質問が上がっていないみたいなので、ちょっと私から質問します。リファクタリングをしなければいけないところって、逆に手をつけられないようなけっこう複雑怪奇な部分だと思うんです。そこらへんはどうすればうまくリファクタリングができるんでしょうっていう（笑）。 高橋：まず、日本人がすごくリファクタリングが嫌いな
ソフトウェアテスト読書マップ
ABCEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAF
テスト技法おさらい（仮）
発表の時に手元で見る用で
Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - 電通総研 テックブログ
みなさんこんにちは、電通国際情報サービス（ISID）Xイノベーション本部ソフトウェアデザインセンターの佐藤太一です。 この記事では、VS CodeのDev Containerを使ってOSに依存しないPythonの開発環境を構築する方法をステップバイステップで丁寧に説明します。 VS Codeの利用経験があり、またPythonによるアプリケーション開発に興味のある方を想定読者として記述しています。Pythonの初心者から中級者向けを意識して書いていますので、意図して冗長な説明をしています。 すでにPythonによるアプリケーション開発に十分に詳しい方は、まずはまとめだけ読んでみてください。私自身それほどPythonのエコシステムに詳しいわけではありませんので、知識の抜け漏れは恐らくあるでしょう。そういった事に気が付いたら、XなどのSNSでこの記事のURLを付けてコメントをしていただけると幸い
PHPカンファレンス2023の登壇資料です。 https://fortee.jp/phpcon-2023/proposal/10143d00-ca44-4db1-aeb6-b618c423b646
読んでよかった book.mynavi.jp 評判通りよかった そっかーなるほどなぁ。面白いなぁ。と思うことがいろいろあった とはいえ、著者の主張全てに同意というわけではなく「著者はそう考えるんだな。自分は違う考えだな」と考えさせられる部分もいくつかあった 苦手な部分もあった 古典学派とロンドン学派に分けて話を展開しているのはあまり好きじゃないなと思いながら読んだ 定理やマトリクスに当てはめて話を展開する部分があって、いくつかは無理やりだったり話をややこしくしていたりするように自分は感じた。そういう部分は苦手だなぁと思いながら読んだ というのが全体の感想。内容はとてもよかったし、苦手な部分もそれはそれで考えさせられたので、読んでよかった。ってことでパラパラめくりながらメモを書いていこう あらためて意識したい2本 「第4章 良い単体テストを構成する4本の柱」の中の2本が、当たり前のことではあ
**テスト駆動開発(TDD)で基礎を身につけましょう。**GoはTDDを学習するのに適した言語です。なぜなら、学習するのが簡単な言語であり、テストが組み込まれているからです。
この記事は、弁護士ドットコム Advent Calendar 2019 - Qiitaの2日目の記事です。 TL;DR TDDの実践方法を実際にコードを書いて解説します TDDの「レッド・グリーン・リファクタリング」のリズムを学ぼう 何度もテストを実行して、プログラムに対する不安を取り除こう TDDはテスト技法ではなく設計手法 TDD Boot Camp Sendai 9thに参加しました。TDDの伝道師和田さん（@t_wada）を講師に迎え、有志たちで開かれた勉強会でした。 午前中は和田さんによるTDDに関する講演とライブコーディング。午後は参加者同士のペアプロで出題されたお題を実装していく活気あるイベントでした。 イベントを通じてTDDはテストファーストのことだと考えていた自分は目を見開かされました。TDDは単にテストファーストでプログラムを実装することではなく、実装（ソフトウェア）が
フロントエンド刷新プロジェクトを成功に導くためのテスト手法の紹介 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロリアでQAエンジニアをやっている中園です。 現在サイボウズではkintoneのフロントエンドリアーキテクチャプロジェクト（フロリア）と称して、Closure Tools から React へと置き換えるプロジェクトが進行中です。 今回は、フロリアのチームの1つであるMiraチームのテスト手法について紹介します。 フロリアの詳細については次の記事をご覧ください。 フロリアについて フロリアでは、次のような構成でそれぞれのチームがオーナーシップを持って活動しており、テストの方針はチームごとに決めています。 プロダクトオーナー: 1名 エンジニア: 3-4名 QA: 1名 スクラムマスター: 1名 フロリアのチーム構成 チームのミッションに合わせたテストの目的 Miraチームでは、kintoneのデザインやふるまいを変えずに、利用者に気づかれない形でReactに置き換えるというミ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ChatGPT使い方総まとめ - Qiita
【翻訳】テスト駆動開発の定義 - t-wadaのブログ
テストの学習へようこそ！ | web.dev
DI (依存性注入) って何のためにするのかわからない人向けに頑張って説明してみる - Qiita
モックは必要悪で、しないにこしたことはない - blog.8-p.info
たった２つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita
テスト、正常系から書くか異常系から書くか - hitode909の日記
ChatGPT、何が問題か 元グーグル社員「非常に無責任で無謀」：朝日新聞デジタル
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
テストコード導入奮闘記～私はこうやってプロジェクトにテストコードを導入しました～ - Qiita
テストの説明に安易に「正しく」とか書かない - Object.create(null)
Storybookを書くだけでリグレッションテストが 実行される世界へようこそ
C#でまともなアプリ開発を行うために - Qiita
私のフロントエンドディレクトリ構成・テスト観点 2022
ユニットテストってもう言わない！ CI/CD時代のテスト分類に最適なテストサイズという考え方
TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング
実践！ ユニットテスト入門
privateメソッドのテストって書かない方がいいんだっけ？
フロントエンドの"ちょうどいい"自動テストのはじめかた - Atrae Tech Blog
テストピラミッド万歳 | POSTD
「まともに単体テストを書ける人は実はすごく少ない」 市場バグを発生させない“単体テストで対処する”という考え方
「SafeTest」がすごい ー Netflix内で利用されている、新しいフロントエンドテストライブラリ
良いテストとは何か:持続可能で保守性の高いテストを書く
単体テストの考え方/使い方を読んだ。読んでよかった。 - Mitsuyuki.Shiiba
テスト駆動開発でGO言語を学びましょう | テスト駆動開発でGO言語を学びましょう
テスト駆動開発（TDD）とは何か。コードで実践方法を解説します - パンダのプログラミングブログ
yoi.shueisha.co.jp
yoi.shueisha.co.jp
www.japhon.work
yoi.shueisha.co.jp
magcomi.com
yoi.shueisha.co.jp