モダンなテストレベル設計（ユニットテスト～システムテスト等をどう設計するか）の原則 - 千里霧中
プロジェクト全体のテストを組み立てる際に重要な課題になるのが、テストレベル設計です。テストレベル設計は、ユニットテスト、結合テスト、システムテストといったテストレベルを、どのような責務・段取りで行うか分析・設計する活動です。 このテストレベル設計ですが、ここ10年程度の間に望ましいアプローチが変わってきたと感じています。今回はこの変化と、変化後のモダンなテストレベル設計の原則について、考えていることを書き出したいと思います。 旧来のテストレベル設計のアプローチ 旧来、このテストレベル設計では、Vモデルをベースしたアプローチや、自工程完結・品質積み上げをベースとしたアプローチがよく見られました。 このうち一つ目のVモデルをベースとしたアプローチは、要求定義から設計までの上流工程への対応を観点に、テストレベルを設計するものです。 （Vモデルが必須と明言しているわけではなく、極端な例ですが）例え
なぜテストコードを書くのだろう? - Uzabase for Engineers
こんにちは、NewsPicksの北見です。 ところで皆様、テストコードって書いてますか...? ネットでテストコードについて検索すると 「テストコードを書きましょう」 「テストコードとはこうあるべし」 「TDD(Test Driven Development)だ」 等々が叫ばれています。 ただ、なんとなく「方法論ありきでとにかくテストを書け」と言われているようで、テストの必要性について納得感に欠けている方もいらっしゃるのではないでしょうか? なぜ テストコードを書くのでしょうか? テストコードを書く理由 将来リファクタリングをしやすくする テストコード書く途中で、開発者自身が仕様を理解し、成長できる 最後に テストコードを書く理由 諸説ありますが、私が思うテストコードを書く理由は 将来リファクタリングをしやすくする テストコード書く途中で、開発者自身が仕様を理解し、成長できる の2つです。
フロントエンドにおける「単体テストの考え方/使い方」
本稿における「単体テスト」とは自動テストにおける単体テストを指します。手動テストのことではないので、ご了承ください。 単体テストの考え方/使い方という本を読みました。筆者自身、「単体テストはプロダクションコードの付属」という意識がどこかにありました。この本を読んで、単体テストについてあまりに何もわかってなかったことに気付かされ、単体テストの設計はプロダクションコードの設計と同じくらい重要という意識に変わりました。何のために単体テストをやるのか、いいテストとは、「単体」とは、など多くの点で学びを得られ、また、多くのプラクティスとアンチパターンを知ることができました。 本稿はこの本を読んで得られた学びを、フロントエンド開発、特にコンポーネント開発に適用することを試みた際のまとめです。より詳細な解説を求む方には本を手に取ってもらう前提で、できるだけポイントを抑えられるようにまとめることを目指しま
【考察】テストコードのきれいな書き方 - Qiita
作ったものが想定した動作をしているか。 それを確認するために、テスト（試験）を行います。 検証したいことがちゃんと実現できて確認が取れているのであれば、その品質自体は割と気にされないことが多い印象です。 保守・運用・追加開発 をしていくプロジェクトが多くあると思います。 その作業の中で、改善を取り入れていくこともあると思いますが、その中でも一番後回しにされるのが、テストコードの改善のように思います。 推測ですが、「コストによるメリット・リターンが少なすぎる」ことが理由かな…と（開発者目線ではリターンが大きいのですが、運用者目線ですとリターンが少なく見えてしまう）。 であれば、最初からある程度綺麗なものがどういうものかを考え、作成しておけば良いのではないか・・！ ということで、考察していきたいと思います。 前提 考察をするにあたり、言語化した時の表現や意味のズレが発生しやすい部分もあると思い
自動テストはなぜあまり書かれてこなかったのか 和田卓人×倉見洋輔×古川陽介がひもとく、フロントエンドテストの歴史
セッションテーマはフロントエンド開発テストの「必要性」と「歴史」 古川陽介氏（以下、古川）：さて、次のパネルディスカッションは、「フロントエンド開発テスト最前線」というタイトルで発表していこうかなと思います。 ご登壇いただくのは、タワーズ・クエスト株式会社取締役社長の和田卓人さんです。和田卓人さんはリクルートの技術開発の技術顧問をやっています。 また、株式会社リクルート兼株式会社ニジボックスの倉見洋輔さんもお呼びして、今回は話をしていこうかなと思います。倉見さんに関して言うと、どちらも私の直属のメンバーというかたちで、一緒に働いています。 今、プロダクト開発において、やはりテストというのが開発の生産性などを決める上でもかなり重要な要素になっているかなと思っています。この必要性や歴史を3人で話していけるといいなと思っています。 テスト駆動開発の第一人者・和田卓人氏 古川：じゃあ、もう始めてい
「バグをたくさん見つける人の頭の中」を言語化してみた - Qiita
バグ発見にはセンスがあるらしい？ 「よくそのバグ見つけたね！」 と言われる人が周囲にいませんか？ 実は私も言われます ただ、「なんで見つけられるの？と言われても...」と思うくらい無自覚だったりします そんな自分を知るためにも今回は、バグを見つけるセンスの言語化に取り組んでみようと思います 注意書き 大前提、体系化も裏付けもできておりません 本来の品質保証やテスティングは、センスでバグを見つける活動ではないとも考えています よくバグを見つける人の頭はこうなっているのかもな、という一例としてお読みください また、この記事では用語の解説は行いません 気になる言葉があればぜひ調べてみてください！ では、「バグをたくさん見つける人の頭の中」を解体していきましょう！ 分類1: 視点を広げる ✅ 無数のユーザーになりきってみる ユーザー面: 中高生だったら？ビジネスマンだったら？高齢者だったら？日本語
【PdM×QA】QAチームがいなくても品質と改善スピードを維持する方法｜藤澤桃子
こんにちは、コネヒトでプロダクトマネージャー (PdM) をしている藤澤です。 コネヒトアドベントカレンダー2022の12日目の投稿として初めてnoteの記事を書いてみることにしました。 この記事は 社内にQAチームがいない小規模組織のPdM 今まで主に自社完結サービスを作っていたのに、突然他社（クライアント）が絡むプロダクトを作ることになった開発チーム に読んでいただけるとうれしいです 私が担当しているサービス私は ママリのプレゼントキャンペーンサイト を担当しています。 このキャンペーンは、申し込むと抽選プレゼントや全員プレゼントがもらえ、申込時のアンケート回答に沿って後日協賛企業からサービスの案内が来るという座組みになっています。 ママリはキャンペーンにより協賛企業（クライアント）とユーザーをつなぐ役割を担ってます。 QAのやり方がわからない…！数年前、突然PdMに任命され、他社が絡
フロントエンドのテストコードを書くときに大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームの @mugi_unoです！ kintone では フロントエンドの刷新プロジェクト（通称フロリア）が進行中です。 blog.cybozu.io kintone の開発では E2E 主体の自動テストを整備していましたが、 フロントエンドの刷新に合わせて、新たにフロントエンド側でのテストコードを積極的に書いています。 テストを書くことに不慣れなメンバーもいるため、日々 Pull Request 上でのレビューやペア・モブ作業を通じて、知見の共有が行われています。今回はフロントエンド刷新のテストを書いてきた中から、筆者が有用だと感じた知見やノウハウを紹介したいと思います。 目次 💡「実はそれ最初からパスしてるかもしれない」 期待する操作で期待する結果になることを厳密に検証する 他のテストケースによって前提条件を担保する 💡「テストコード上のロジッ
Lintを使う人、作ってみたい人、問題解決の引き出しを増やしたい人のための勉強会Lint Nightを開催します！ - DeNA Testing Blog
SWETグループのLint大好きマンKuniwakです。2022/11/18にオフライン・オンライン同時開催の勉強会「Lint Night #1」を開催します！ Lint Nightはプログラミング言語不問でLintに関するトピックを取り扱う勉強会です。ここでLintとはソースコードや文書を静的に解析して問題をみつけるツールのことです。ただ、どこまでをLintとするかには幅があるようです。 さて、Lintの面白いところはソースコードや文書を入力データとして扱うプログラムであることです。ソースコードを入力データとするプログラムといえばコンパイラやインタプリタがあげられますがいずれも実装がかなり大変です。しかしLintはそこまでではありません！実は手軽に実装できるんです（Lintの作り方については次のスライドをご覧ください）。 しかもそれでいてコードレビューを一部自動化できて実用的ですし、ソー
ユニットテストをGitHub ActionsからCodeBuildに移行し、実行時間を35%削減した - Uzabase for Engineers
こんにちは。NewsPicks SREチームの 海老澤 です。 今回はGithub Actionsで実行していたテストを高速化したので紹介したいと思います。 課題 取り組み テストの並列化 AWS CodeBuildへの移行 CodeBuildの設定 コンピューティングタイプ トリガー buildspec.yml 結果 課題 NewsPicksでは Junitのテスト等をGithub Actions から実行しているのですが、2013年のサービス開始当初から存在する、一番コードベースが大きいリポジトリのビルド・テストの実行時間に 20~30分ほどかかっていました。 テスト自体はバグを産まないためにも必要なものですが、時間がかかるため開発効率が下がってしまいます。そのためテスト高速化の取り組みを行いました。 取り組み テストの高速化をする上でやったことは大きく下の二つです テストの並列化 G
Laravelで "A facade root has not been set." というエラーが出た場合の対処法 - Qiita
use PHPUnit\Framework\TestCase を use Tests\TestCase に変更する。 自前で setUp() を実装した場合は、 parent::setUp() を必ずコールする。 前提 Laravel 6.18.10 1. useするクラスを変更する PHPUnit\Framework\TestCase は Laravel ではなく PHPUnit のクラスです。なので、これを use しても、ファサードを動かすことができず、エラーとなります。 そのため、Laravel のクラスである Tests\TestCase を use する必要があります。 namespace Tests\Unit; // PHPUnit ではなく Laravelの TestCase を使う。 // use PHPUnit\Framework\TestCase; use Tests
puppeteer を使用する · Jest
page.$eval, page.$$eval または page.evaluate をテストで使用している場合、Jestのスコープ外でパスする関数が実行されているため、現時点ではPuppeteerを使用したテストがいつのカバレッジの生成はできません。 Check out issue #7962 on GitHub for a workaround. jest-puppeteer プリセットを使用する Jest Puppeteer は、Puppeteer を使ってテストを実行するために必要な、すべての設定を提供します。 First, install jest-puppeteer
Sentry の運用を最適化して継続していく - スタディサプリ Product Team Blog
こんにちは。フロントエンドエンジニアの @sakamuuy です。 私たちのチームではエラートラッキングに Sentry というサービスを利用しています。この運用を開始して半年が経過しました。 今回は私が所属するフロントエンドチームでのSentry運用について、苦労したこととその打ち手についてお話したいと思います。 はじめに エラーを検知し重大なバグなどに早めに気づくことは、Sentryを運用する一つの目的だと思います。 そのためには未解決のエラー件数をなるべく少なくし、発生したエラーを監視できている状態を保つことが必要だと考えています。この状態を保てるように運用で工夫していることについてお話します。 チーム チームでの運用についてお話する前に、私の所属しているtara学習コアチーム (taraとはスタディサプリ中学講座のリニューアルプロジェクトの通称です) についてお話します。 tara
[Jest] テストのタイムアウト時間を変更する | DevelopersIO
こんにちは、CX事業本部 IoT事業部の若槻です。 今回は、テストフレームワークJestのテストのタイムアウト時間を変更してみました。 test()の既定のタイムアウト時間は5秒 外部のAPIなどを叩くなどの重い処理を実行するテストで、実行時間が長くなってしまう時があります。 例えば次のような実行に5秒以上の時間を要するテストがあります。 test('テスト', async (): Promise<void> => { await new Promise((r) => setTimeout(r, 6000)); //6秒待機 expect(1 + 1).toBe(2); }); Jestで実行してみます。するとAsync callback was not invoked within the 5000 ms timeout specified by jest.というエラーとなりました。 $
![[Jest] テストのタイムアウト時間を変更する | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/e7554255b6506e52c7e3f400d90fa71d111cdad7/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F07%2Fjest_icon.png){kind=icon}
laravelでDBテストコードを書く前の設定すべきこと - Qiita
データベースのテストをする際には、テスト用のDBを用意して、そのDBでテストした方が良い。 理由 テストDBを用意して、テストを実行する際、 DatabaseMigrationsやDatabaseTransactionsを使ってもDBに全く影響を与えないわけでは無いです。 AUTO_INCREMENTの値など、一部は影響を受けてしまいます Laravel 5.4 で手軽にテストを書こう！ | 株式会社インフィニットループ技術ブログ 実際に試してみました。 use DatabaseTransactions;が無い状態で、AUTO_INCREMENTのカラムがあるレコードを追加するコードのあるテストを実行(※以降テスト) use DatabaseTransactions;がある状態テストを実行 use DatabaseTransactions;が無い状態テストを実行 そうするとAUTO_INC
フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022
フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダイジェスト
【Laravel】.env.testingの使用方法と注意点 - Qiita
LaravelでPHPUnitを使うときにテスト用の`.env｀を設定するのにハマったので記事にしました。 環境 Docker 19.03.8 PHP 7.3.16 Laravel 6.18.3 .env.testingの設定方法 本番DBを汚さないようにPHPUnitを実行する時のみテスト用のDBを使うようなことはよくあると思います。 その方法の一つとして.env.testingを作成し、phpunitにその設定値を読み込ませるやり方があります。 .env.exampleをコピーして.env.testingを作成し、以下の箇所を変更します。 APP_ENV=testing // testingに変更 APP_KEY= // 空にしておく // 接続したいDBの情報を設定する DB_CONNECTION=mysql DB_HOST=db DB_PORT=3306 DB_DATABASE=t
React のテストを書いてたら act で囲んでよーって言われたとき - Mitsuyuki.Shiiba
React のコンポーネントのテストを書いてたら、テストは成功してるんだけど、こういう感じの Warning が出力されるって場合がある Warning: An update to Counter inside a test was not wrapped in act(...). When testing, code that causes React state updates should be wrapped into act(...): act(() => { /* fire events that update state */ }); /* assert on the output */ ステートを変更するときは act で囲んでねって書いてある。だから、囲めばいいのかなぁ？って思ってたら、ちょっと触った感じ、どうやらそういうことでもないみたい。ので、うろうろしてたら、この2
はてなブログで使われているフロントエンドのテストツールを統一した話 - Hatena Developer Blog
はてなでエンジニアアルバイトをしているid:wafuwafu13です。はてなブログのフロントエンドで使われているテストツールの統一を2021年11月頃から進めてきましたが、この8月に完了したので振り返りたいと思います。 はてなブログのフロントエンドに残された秩序の乱れ テストツールを統一する理由とツールの選定 移行をどう自動化したか（しなかったか） 余裕のあるスケジュールで小分けして作業を実施 はてなエンジニアのアルバイトは通年で募集中！ はてなブログのフロントエンドに残された秩序の乱れ 2020年のid:nanimono_demonaiさんの活動により、はてなブログのフロントエンドのテストはPhantomJSとKarmaを撤退し、Jestに移行されました。 はてなブログのフロントエンドに秩序はもたらされたのか - Speaker Deck これによって秩序がもたらされたものの、Node.
【Laravel】PHPUnitでテストコードを書くときのTipsやサンプルコード - Qiita
Laravel Advent Calendar 2021 17日目の記事です。 僕自身が書いた経験のある範囲でPHPUnitでテストコードを書くときのTipsやサンプルコードをまとめます。 はじめに いきなりタイトルには直接関係ない小ネタを挟みます。 テスト関連のコマンド テストファイル作成 # tests/Featureに作成される php artisan meke:test SampleTest # tests/Unitに作成される php artisan make:test SampleTest --unit # ディレクトリを指定してファイル作成 # tests/Feature/User配下 php artisan make:test User/SampleTest # tests/Unit/User配下 php artisan make:test User/SampleTest
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
