Puppeteer, Selenium, Playwright, Cypress - how to choose? - AI-driven E2E automation with code-like flexibility for your most resilient tests
Puppeteer, Selenium, Playwright, Cypress – how to choose? At Testim, a lot of what we do is build AI-based features on top of automation frameworks to add stability,… At Testim, a lot of what we do is build AI-based features on top of automation frameworks to add stability, accelerate test creation, and improve root-cause analysis. We evaluate a number of test automation frameworks to understand
Write tests. Not too many. Mostly integration.
A while back, Guillermo Rauch (creator of Socket.io and founder of Zeit.co (the company behind a ton of the awesome stuff coming out lately)) tweeted something profound: Write tests. Not too many. Mostly integration. This is deep, albeit short, so let's dive in: Write tests. Yes, for most projects you should write automated tests. You should if you value your time anyway. Much better to catch a b
- JUnit 実践講座 - プログラミングスタイルガイド
JUnit 実践講座 - プログラミングスタイルガイド 2002/01/02 作成 石井 勝 目次 はじめに 実装コードとテストコードの書き方は違う テストコードで一般解を扱わないこと コメントについて リファクタリングについて メソッド名と本体について テストコードの構成 Footnotes 更新履歴 はじめに XP による開発全体にいえることですが，JUnit を使った開発では，プログラマは次の 2種類のコードを書かなくてはなりません． 実装コード 実際にソフトウェアとして実装されるコード テストコード JUnit を使って書かれるコード 僕の経験では，一般に実装コードよりもテストコードの方がコード量が多く，コードを書くのに費やされる時間もテストコードの方が長くなります．したがって，何も考えずにテストコードを書いていけば，開発の後段階でテストコードが肥大化し，メンテナンスの悪夢に悩まさ
テストコードを書き始める前に考えるべきテストの話 #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
A Journey Through Client-Side Testing with JavaScript - Telerik Blogs
Having tests is important. They allow us to extend and refactor our code with ease. Many developers follow test driven development as a workflow. I believe that writing tests makes software development much more interesting and generally leads to better code. Well-designed and tested systems are easier to maintain. Over the last few years, developers have begun to put a lot of application logic in
Acceptance Tests at a Single Level of Abstraction
Each acceptance test tells a story: a logical progression through a task within an application. As developers, it’s our responsibility to tell each story in a concise manner and to keep the reader (either other developers or our future selves) engaged, aware of what is happening, and understanding of the purpose of the story. At the heart of understanding the story being told is a consistent, sing
テスト駆動型開発についての議論 - ワザノバ | wazanova
http://blog.testdouble.com/posts/2014-01-25-the-failures-of-intro-to-tdd.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約7時間前 Test Double社がブログで、TDD (テスト駆動型開発) を教える場合のアプローチを提案しています。 TDDについて、同じ用語やツールを使っていても、「モックオブジェクトがありすぎて、ひどい。」「モックオブジェクトがあふれていて素晴らしい!」という異なる見解に至るケースがでてしまっているのは、理想的なゴールに至る道筋を統一したかたちで教えきれてないからだと指摘しています。 TDDの一番の効果はコードのデザインの改善であり、コードのクオリティの担保は、うまくいけば二次的な効果、まかり間違えば幻想
Rails の ActiveRecord モデルテストの書き方ガイドライン - passingloopの日記
このエントリでは，Ruby on Rails （以下 Rails）の ActiveRecord モデルテストについて，1) どこの何をテストすればよいか，2) どのようにテストを書けばよいか，のガイドラインを示します．このガイドラインは Rails 公式のものではなく，id:passingloop が使っている私的なものです．疑問・質問・批判・間違いの指摘はページ下部のコメント欄までお願いします． はじめに Rails は TDD/BDD サポートが充実した Web アプリケーション開発フレームワークです．Rails で使える Test::Unit や RSpec などといったテスティングフレームワークの使い方に関する解説も豊富にあります．しかし，「どこをどうテストすればよいのか」についての解説は，「使い方」の解説と比較して少ないように思います．もっとも，テスト一般についてどう書くかはアプ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テスト用の模擬クレジットカード番号一覧 | WebPay: Ruby開発者向けクレカ決済サービス
Write Reliable, Asynchronous Integration Tests With Capybara