DIと単体テストと私: 緩やかな依存関係がもたらすメリット
はじめに この記事は、アルサーガパートナーズ アドベントカレンダー2023、番外編の記事です。 「25日間のリレー」を成功に導いた素敵な記事たちがカレンダーに集まっていますので、よろしければ下記のリンクからご覧ください！ この記事について 実務における最初の壁: DI 未経験からエンジニアとして実務に携わるようになると、誰しも「独学でやっていた時とは違うな」と感じることがたくさんあると思います。 私のサーバーサイドエンジニアとしてのキャリアはLaravelによる開発からスタートしたのですが、そんな私にとっての最初の「自己学習と実務の違い」の1つは、DI(Dependency Injection, 依存性注入) の概念が実装に利用されていること、でした。 すでに実装されている先輩方のコードを読めば「どう書けばいいか」はある程度すぐに把握できたものの、概念の理解を進めようとしても抽象的で難解な
【初心者向け】Goのテストにおけるベストプラクティス - Qiita
前提：テストをなぜ行うのか？ 「そもそもなぜテストをするのか」、目的をもってテストを書いていますか？ テストの目的を知ることで、何のテストが必要か、どんなテストを書くべきかが迷わなくなると思います。 調べたり、実際に書いてみて自分が感じたことは、以下の 3 つです。 コードの質を向上させる（バグ発見、処理の高速化など） 開発の過程で機能を追加したらなぜか動かなくなったり、直したはずのバグが復活することありませんか？ そのときにログやコードを読んで、バグを手動で見つけるのはすごく困難です。 テストを書くことで、機能を変更しても動作確認やバグの発見が容易に行えます！（とても便利） コードを書いた人の意図を明示する 他の人が書いたコードは読みにくいと感じる人が多いと思います。 この理由の一つに、「コードを書いた人の意図や頭の中の仕様を理解できない」というのがあると思っています。 テストを書くこと
テスト駆動開発者を増やした社内勉強会｜NAVITIME_Tech
🎄この記事はNAVITIME JAPAN Advent Calendar 2023の4日目の記事です こんにちは、ネコ派メタラーです。 ナビタイムジャパンでスポットデータ運用基盤の開発を担当しています。 開発業務を担当する一方で品質管理部門にも所属しており、開発プロセスの改善を通してプロダクト品質を改善する活動もしています。 開発プロセス改善の一環で、今年8月からテスト駆動開発 (Test Driven Development、以下「TDD」) を学ぶ社内勉強会を開催しています。この記事ではこの勉強会の運営、および得られた効果についてご紹介します。 きっかけ当社の品質管理部門では、自動単体テストの実装を推進し、網羅率改善などの成果を挙げてきました。一方、親和性が高いテクニックとして TDD に言及する機会もありましたが、価値を認めつつも従来の開発手法からなかなか脱却できない実態がありまし
チームで学ぶTDD輪読会 - コドモン Product Team Blog
こちらはコドモン Advent Calendar 2023の11日目の記事です🎅 qiita.com こんにちは！コドモンプロダクト開発部の村松です。 コドモンでは1週間につき半日、業務時間を自己学習に使える0.5投資制度があります。 今回は0.5投資制度を使い、チーム内で行ったTDDの輪読会について紹介します！ 輪読会スタートの背景 輪読会の進め方 輪読会のメリット チームでの変化 テストを先に書くのが当たり前に 小さくテストし、開発サイクルを回す意識 問題の言語化と改善 todoリストの活用 おわりに 輪読会スタートの背景 コドモンでは以前、t_wadaさんにレガシーコード改善ワークショップを行っていただきました。 tech.codmon.com ワークショップをきっかけにTDDへの関心がチーム内でも高まったので、今回の輪読会はTDDをテーマにスタートしました。 輪読会の進め方 輪読
リファクタリングを文化にする 〜組織が技術的負債と向き合うワークショップ〜 - MonotaRO Tech Blog
皆さんこんにちは。 CTO-Office の香川とEC開発-Bグループの竹原です。 11/28に 和田卓人氏(id:t-wada)を講師としてお招きしてテストとリファクタリングのためのワークショップを開催いたしました。 技術者正社員のうちプログラミングをすることの多いメンバー全体の約1/3にあたる総勢53名が参加しての開催となりました。 本記事ではまず第一弾としてワークショップの概要や目的、全体の流れについて簡単にご紹介いたします。 また第二弾(2024年1月公開予定)では、運営とワークショップの問題の作問に関わったメンバーにそこでの学びや実践について紹介いただきます。 開催に至った経緯とMonotaRO DOJO MonotaRO DOJO とは 社内の課題とワークショップの目的 開催経緯 ワークショップの全体像と開催までの段取り ワークショップの全体像 概要 タイムテーブル 開催までの
テスト駆動開発のはじめの一歩｜t_wadaさんに聞く1人で始める自動テストのコツと考え方 - Agile Journey
アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発（TDD：Test Driven Development）です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分
ユニットテストで避けるべき罠： 最適な品質保証のために落とし穴を避ける - Qiita
はじめに 新卒として、実務に入って3ヶ月目のお話。なぜかテストコードの正式な導入の動きにより、先輩から、「テストコードの規約かいて〜〜〜」と超ラフに言われ、「ん？」となりつつ、作りました。そんな中で、テストコードの作成やお試し実装などをしている時に、みんなこれハマるよな...というものをざっと上げてみます。 ユニットテストにおけるテスト自動化は、システムのテストにおいて最も難易度が高いと言われているそうです。その要因の1つとして、やはり注意すべき点や陥りやすい罠が多いことが挙げられます。この記事では、テストコードの一般的な罠に焦点を当ててみました。 対象の読者 今後、会社にユニットテストを導入しようと考えている人 品質管理をしているエンジニア テストコードに興味があるエンジニア 1. Over-Testing と Under-Testing テストをする上で、テストシナリオとして必要なもの
research!rsc: Go Testing By Example
I opened GopherCon Australia in early November with the talk “Go Testing By Example”. Being the first talk, there were some A/V issues, so I re-recorded it at home and have posted it here: Here are the 20 tips from the talk: Make it easy to add new test cases. Use test coverage to find untested code. Coverage is no substitute for thought. Write exhaustive tests. Separate test cases from test logic
JUnitで学ぶ実践的で本質的なユニットテストの考え方 - Qiita
初めに 具体的なコードや方法も記述しますが、それよりも JUnit などの自動テストのFW、ユニットテストの概念や目的など本質的なことを把握し理解する事を主題にしてます。 また、参考資料欄にあるように、様々なものを参考に網羅的にまとめています。非常にボリュームがるので興味あるところだけ読んでもらう方が良いかもしれません。 こちらでは、ある程度開発経験（1〜2年程度）があり、自動テストについて少しでも触れた事があるくらいの方が対象になる記事です。自分がそうだからです。ただし、コンパイルエラーにならないだけの書き方では意味がないのでそういった構文やお作法に関する話はあまりしません。なぜそのようなお作法になったのか？そうである理由は何なのか？トレードオフは？といった、本質的な部分にフォーカスを当てていきたいと思います。 1. 概要 JUnit は Java 言語向けのユニットテストフレームワーク
t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
チーム開発を加速するテストの育て方
テストを書いてないというチームには色々理由があると思いますが、「何をテストすべきかわからない」「書き方がわからない」「どのくらいメリットがあるかわからない」という意見は多いのではないでしょうか？テスティングフレームワークの選定や使い方を学ぶのは重要ですが、それ以上にテストの目的や戦略を学ぶことが重要です。チーム開発においてテストを活かすのは相応の知識とスキルが必要になりますが、活かせればテストは開発スピードを維持・促進する飛び道具になり得ます。 本稿は筆者が取り組んで実際に高いチーム満足度と速度を得られた、テスト戦略についてまとめたものです。
pytest で E2E テスト
pytest で E2E テストが本当に便利です。 実際どう使っているかを紹介しておきます。 なぜ Python でテストなのか 自分が Python に慣れている 自分にとって pytest を超えるテストランナーが今のところない SpaceX がテストを Python で書いてて、じゃぁ Python でいいかとなった https://old.reddit.com/r/spacex/comments/gxb7j1/we_are_the_spacex_software_team_ask_us_anything/ft0bz35/ We use C & C++ for flight software, HTML, JavaScript & CSS for displays and python for testing. Rye のおかげで Python の環境構築が苦にならなくなった htt
Rails のブラウザテストを Playwright で動かすようにしたらデバッグが簡単になって捗った
Omotesando.rb #91 (https://omotesandorb.connpass.com/event/299381/) で発表した資料です。
テスト駆動開発(TDD)ハンズオンのすすめ - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは、あるいはこんばんは。すぱ..すぱらしいサーバサイドのエンジニアの(@taclose)です☆ 弊社では先日テスト駆動開発（以降、TDDと呼ぶ)ハンズオン勉強会を開催しました！ 今回の記事の内容はズバリ２つ 誤解してる!?テスト駆動開発の良さ！学ぶ事の意味！ TDDハンズオン勉強会を開催する意図や実施内容、感想！ 読者のターゲットは TDDを誤解している人 TDDハンズオン勉強会を弊社でもやろう！とか思ってる人 を想定していますっ。 誤解されがちなTDD、記事にするには書ききれないTDD...なるべく小難しい内容は省いて興味を持ってもらうための記事を書いてみようと思います！ テスト駆動開発（TDD）は良い物だ！ テスト駆動開発（TDD）とは何か？ TDDに対する誤解 TDDハンズオンについて TDDハンズオンの趣旨 TDDハンズオンの計画 事前準備 スケジュールと概要 TDDハンズ
新しく公開された Distributed Load Testing on AWS (DLT) ワークショップを試した - kakakakakku blog
負荷テストを実行したいけど，ラップトップや Amazon EC2 インスタンス1台から実行すると負荷テストを実行する側がボトルネックになってしまって，期待した負荷テストにならないという悩みはよくあると思う🔥 そこで負荷テスト専用の SaaS などを活用して負荷テストを実現する案もあるけど，AWS では「AWS ソリューションライブラリ（サービスではない）」として負荷テストを実行・管理する「Distributed Load Testing on AWS (DLT)」が提供されている❗️ aws.amazon.com 僕自身は2年ほど前に Distributed Load Testing on AWS (DLT) を検証したことがあるけど，最近 Distributed Load Testing on AWS (DLT) を体験するワークショップ（日本語🇯🇵）が公開されたらしく，復習も兼ね
オブジェクト指向で書く！テストのしやすいプログラム
概要 関数の組み合わせで作られているテストしにくいプログラムから、オブジェクト指向で書かれたテストのしやすいプログラムにリファクタリングを行う中で、クラスを用いてプログラムを書くとどのような嬉しいことがあるのかについて説明させていただければと思います。 今回使用したソースコードなどは以下に置いてあります。ご自分で実行しながら読まれても面白いかもしれないです。 想定読者 オブジェクト指向について、聞いたことはあるけどイマイチピンとこない ソースコードに単体テストを入れようとしてるけど、具体的にどのように入れればいいのかわからない いまいちクラスを用いてプログラムを書くことの利点がわからない クラスがどのようなもの何かについては理解している 前提としている知識 単体テストの基本的な考え方 TypeScript（ご自身の得意とされている言語にも同じような機能はあるはずですので適宜読み替えていただ
テストケースの名前には条件と結果を含めた方が良い - 感情を込める
という考えにたどり着いたので、考えのスナップショットをとっておく。 Go言語における、テスト関数名とサブテストのname引数の値を「テストケースの名前」・「テスト名」と呼ぶことにしている。 (*testing.T).Run(name string, f func(t *testing.T)) bool テスト名に近いものとして、(*testing.T).Errorや(*testing.T).Logの引数がある。これらはテスト実行時の出力に含まれるが、テストケースを分かつものではない。あくまで、特定のテストケース内の情報を増やすものだ。対するテスト名は、（通常は）テストケースを分割できる最小単位である。 テストケースがテスト名の単位で存在するということは、テスト名はそのテストケースを十分に表現できていたほうがよいということだ。さもなくば、検証・変更しようとする仕様に対応するテストケースや、実
「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム（仮）による若手育成の取り組みについて
GAME CREATORS CONFERENCE '20の講演資料です。 動画のURL：https://youtu.be/jTIIeKKM68Q 『「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム（仮）による若手育成の取り組みについて』 株式会社セガ 第1事業部 阪上直樹
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
古典学派的テストとGoで考える持続可能なアーキテクチャ入門
サバンナ便り〜自動テストに関する連載で得られた知見のまとめ（2023年5月版）〜 / Automated Test Knowledge from Savanna 202305 edition
