Cypress vs Selenium vs Playwright vs Puppeteer: SpeedMonitoring as codeUnite E2E testing and monitoring in one developer-focused monitoring as code (MaC) workflow. Synthetic MonitoringOpen Source based E2E automation to monitor your web app continuously.
Migrating from Puppeteer to Playwright | Checkly
The switch from Puppeteer to Playwright is easy. But is it worth it? And how exactly does one migrate existing scripts from one tool to another? What are the required code-level changes, and what new features and approaches does the switch enable? UPDATE: you can use our puppeteer-to-playwright conversion script to quickly migrate your Puppeteer codebase to Playwright. Puppeteer and Playwright tod
Testing in the Twenties
[This fragment is available in an audio version.] Grown-up software developers know perfectly well that testing is important. But — speaking here from experience — many aren’t doing enough. So I’m here to bang the testing drum, which our profession shouldn’t need to hear but apparently does. This was provoked by two Twitter threads (here and here) from Justin Searls, from which a couple of quotes:
On the Diverse And Fantastical Shapes of Testing
Pyramids, honeycombs, trophies, and the meaning of unit testing There's been a recent resurgence on twitter and the like about how teams should divide up their testing efforts. In particular, Tim Bray argues compellingly in favor of taking automated testing seriously. Anyone familiar with my writing will know that I'm very much in agreement with him. One of the points he raises in his post refers
「さよなら Flaky 。不安定なテストの探し方」というお話 - Cybozu Inside Out | サイボウズエンジニアのブログ
みなさんこんにちは。サイボウズの三苫です。 本日は特にどこのイベントでも発表する予定もなく、実際に発表されなかった、不安定なテスト(Flaky Test)対策のお話をスライド & トークスクリプト形式で公開します。 不安定なテスト対策は、どこの現場でも継続的にされているかと思いますが私たちの一つの事例が皆様の対策の一助となれば幸いです。 さよなら Flaky 。不安定なテストの探し方 皆さんこんにちは。サイボウズの三苫と申します。本日は「さよなら Flaky 。不安定なテストの探し方」というお話をします。 私たちのお悩みごと 早速ですが私たちが抱えていた悩み、つまり前提となる課題からお話します。 サイボウズの kintone.com 基盤チーム(私の所属するチーム)はE2Eテストを使って AWS 上に構築した基盤上で kintone というサービスの動作保証をしようとしていました。 幸運に
Test Flakiness - One of the main challenges of automated testing (Part II)
There are two main reasons for flaky automated tests. 1) Poor Locator Strategy. Find a methodology that is testable before you have to depend upon it in your automated testing. I just posted a video on this topic a week ago, which shares why our team exclusively utilizes xPath for some of the most reliable locators you can build. Realize xPath has got a bad rap and is often demonstrated online in
Reducing flaky builds by 18x
EngineeringReducing flaky builds by 18xPart of the Building GitHub blog series. It’s four o’clock in the afternoon as you push the last tweak to your branch. Your teammate already reviewed and approved your pull request… Part of the Building GitHub blog series. It’s four o’clock in the afternoon as you push the last tweak to your branch. Your teammate already reviewed and approved your pull reques
Test Flakiness - One of the main challenges of automated testing
What I would like to see is a breakdown of how many failures fall into which category. And of the above categories, while useful for root cause analysis and eventual fix, for sake of triaging results, and disposition of what to do if hitting such a failure, it seems that whether or not the failure is a true product failure is a HUGE difference from the other three. For the other three, the major r
A machine learning solution for detecting and mitigating flaky tests - Engineering Fitness
If you are a developer you’ve probably experienced flaky tests or flakes and the first thing that comes to your mind is either frustration or annoyance. In this post we are going to discuss how we are dealing with flaky tests here at Fitbit and what our plans are for solving this problem. Before we go into any details, let’s level set on what flaky tests are, why they are bad and also go through s
自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み
長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています（経歴）。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に
Should I Test Private Methods?
should i test private methods?
Testing on the Toilet: Tests Too DRY? Make Them DAMP!
I get what the author is going for here, but I don't totally agree with them. I think the easiest and cleanest approach is to move the list of users out of set up and into the test (as the author recommends), but personally I would keep the loops and reorganize the code a bit to make it easier to read, so kind of like a DRY DAMP approach? pseudo code: def register_list_of_users(user_list): to_retu
レガシーコードは南斗聖拳(外から攻める)。新規開発は北斗神拳(内から攻める)、レガシーコード改善ガイド読書会ふりかえり - 未来のいつか/hyoshiokの日記
社内テスト勉強会でレガシーコード改善ガイド読書会の報告をした。 読書会を地味に開催してテストの価値観を共有できたのは非常によかった。そして実際、自分のプロジェクトに試してみた人たちの報告もあった。 一方で社内読書会の課題も見えてきた。やはり、参加者のスケジュール調整が難しいこと、少しずつ参加者が減ってしまうことなどである。皆忙しいし、時には突発のトラブルでスケジュールどおりに参加できない事はある意味致し方ない。忙しいと読書会どころではなく、それに参加しつづけるモチベーションの確保も難しい。*1 レガシーコード改善ガイド読書会View more presentations from Hiro Yoshioka. 今あるレガシーコードとどう向き合うか 新規にソフトウェアを作る場合はTDDでユニットテストを書いていけばいい。この方法論についての報告、参考書などは豊富にある。 レガシーコードという
Truth 1.0: Fluent Assertions for Java and Android Tests
Post a Comment The comments you read and contribute here belong only to the person who posted them. We reserve the right to remove off-topic comments. TotT 77 GTAC 61 James Whittaker 42 Misko Hevery 32 Anthony Vallone 27 Patrick Copeland 23 Jobs 18 Code Health 13 C++ 11 Andrew Trenk 10 Patrik Höglund 8 JavaScript 7 Allen Hutchison 6 George Pirocanac 6 Zhanyong Wan 6 Harry Robinson 5 Java 5 Julian
ReportPortal test automation analytics platform and real-time reporting, powered by Machine Learning
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Justin Searls on Twitter: "People love debating what percentage of which type of tests to write, but it's a distraction. Nearly zero teams wri… https://t.co/pZDIJBePOE"
How to Make 100 Releases Per Day with Only 6 Quality Engineers
GitHub - sorry-cypress/sorry-cypress: Open-source, free, self-hosted alternative to Cypress Dashboard
GitHub - microsoft/playwright: Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.
組織にテストを書く文化を根付かせる戦略と戦術（2019夏版） / Strategy and Tactics of Building Automated Testing Culture into Organization 2019 Summer Edition
