Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに Playwright を使うことで比較的簡単に E2E テストを実装することができます。しかし、通常テストコードは実装したら終わりということではなく、継続的にメンテナンス(保守)が必要になります。その際に保守しやすいように実装するため、Playwright の公式ドキュメントに記載されているベストプラクティスの中で参考になりそうな部分を確認しておこうと思います。 テストの独立性を高める 可能な限りテスト間の依存が無いようにして、テストを分離すると良いというプラクティスです。各テストが独立していることで、 1つのテストが失敗しても他のテストに影響しない テストの順序を考慮する必要がない テストをシンプルに保つことができる あたりのメリットがあるかと思います。また、特定の処理(例えば特定の URL に遷移する処理)の繰り返し実装するのを避けるために before and after
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は? 皆さんお久しぶりです。@cosmeの開発エンジニアをしております、村田です。@cosmeを運営する株式会社アイスタイルではPHP -> TypeScriptへの技術移行を進めており、フレームワークとしてはexpress, oclif, そして本記事で紹介するJavaScript製のテスティングフレームワークであるjestなどの各種ツールを使って開発を進めています。 この記事で紹介する内容は、チームでテストコードを書く文化を定着していく話です。というのも、既存プロダクトにて元々テストコードが十分に書かれていない部分があったた
RSpec.describe HogeHoge do describe '#foo' do # Act subject { hoge_hoge.foo } # Arrange let(:hoge_hoge) { HogeHoge.new } before do # これもArrange hoge_hoge.bar = 1 end # Assert context '●●の場合' do it 'trueを返すこと' do is_expected.to eq true end end end end モックは必要最小限に、でも有効に使用する テストにおいて「本物のフリをする偽オブジェクト」であるモックは非常に強力で有用です。特にテストコードを書く上で大いに悩ませる下記2つのような問題を解消できることはとてもありがたいです。 下位アーキテクチャ層の全ての挙動を考慮してテストコードを記述する必要が
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Codemagic は、今年の2月に発表された Flutter UX 調査チームによる Q4 2019 の調査結果において、開発者が CI/CD で採用しているサービスのトップ3に挙げられており、(Codemagic、 Github Actions、 GitLab)、その中でも満足度が最も高かったことが示されています。 Codemagic は、Google と提携して Flutter 専門の CI/CD サービスとして開始されただけあって、Flutter を手厚くサポートしています。また、以下の翻訳で示されているように、Flutter
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 分類については独断です。また、こつこつ「ひとこと説明」を追加していく予定です。 Selenium関連については Awesome Selenium : 素晴しい Selenium ライブラリの数々 - Qiita が参考になります。 FAQ なんで***を除いているのか 恣意的に除いていることはないので、編集リクエストかコメントをください GUIテスト自動化ツール モバイル・デスクトップアプリ・ブラウザのうち複数の対象のGUIを操作できるテスト自動化ツール。 有料 インストール型 UFT One QTP(Quick Test Profes
はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう!』 『今までモック使ってたけど意外とモック使わなくても書けるね!』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 もくじ テスト駆動不具合修正 or リファクタリング手順 なぜテストが書けないのか 依存関係を排除できればテストは書ける 依存関係を排除するためのカギになる考え方 書けない単体テストがなくなる2
背景 FlutterでFirebaseを組み込んだアプリのWidgetテストを行おうとすると、一向にテストが終わらない現象が発生したので備忘録として残します。 結論として、Firebase.initializeApp()がプラットフォーム上でないと動作しないために発生している事象のようなので、Mockを用意してあげることで解決しました。 コード testWidgetの中でFirebaseを初期化しようとしています。これがないとWidgetテスト実行時に No Firebase App '[DEFAULT]' has been created - call Firebase.initializeApp() と怒られていたために記述していました。 void main() { testWidgets('Counter increments smoke test', (WidgetTester t
Playwright が昨年1年間で大幅パワーアップしていたので、使い方を確認したときの記録のまとめです。 ブラウザを自動操作できるということは、簡単なスクレイピングやブラウザ側のテスト自動化が簡単にできるようになります。 特に、Python での解説がまだまだ少なかったので、自分の学習を含めてまとめました。 今回は入門編ということで全体像をつかみつつ使用方法の流れを確認していただければありがたいです。 Selenium や Puppeteer を使っている方も、一度試す価値ありと思っています。 選定した理由 ブラウザのテストを Python で自動化したかったんです。 私なりの要件がありまして、非常にわがままな要件でしたが余裕ですべてクリアしました。 Python で書けること。社内で Python を使える方が多いので。pytest と連携してくれるとなおうれしい。 Docker コン
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 自動テストがほとんど整備されていないRailsプロジェクト、かつテスト文化がなかったチームに、約1年ほどかけてテスト文化を根付かせたことについてお話したいと思います。 経緯 当プロジェクトは、当初はCIは整備されているものの、テストはわずかに書いてあるのみでメンテナンスされないまま放置されており、CI上でもテストが失敗していることを無視してリリースされてされていました。 ある時、大きめの不具合を起こしてしまい、再発防止を考える上でせっかくCIでテストが回るようになっているのであればということで、本格的にテストを書いていくことを
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TDDは死んだ。テスティングよ栄えよ。 by DHH http://d.hatena.ne.jp/yach/20140424#p1 【翻訳】TDD is Fun http://diskogs.hatenablog.com/entry/2014/04/25/085112 を読んで思ったことをつらつらと書いてみます。 TDDはできれば、やったほうが良いのは確か?です。 しかし、実際の開発現場で全面的に採用するのは ミドルウェア等の画面の存在しないソフトの開発以外では ほとんどの場合、無益です。 なぜなら、TDDを採用すると開発時間が膨らむ、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く