Chrome 97のDevToolsに新機能、Webブラウザ上の操作を記録、再実行、編集、保存。Puppeteerスクリプトへのエクスポートも
Chrome 97のDevToolsに新機能、Webブラウザ上の操作を記録、再実行、編集、保存。Puppeteerスクリプトへのエクスポートも Googleは、来年1月に登場予定のChrome 97で、DevToolsにWebブラウザ上での操作内容を記録し、再実行や編集、保存などを可能にする新機能を搭載することを明らかにしました。 Introducing the new Recorder panel You can now record, replay and measure user interactions with @ChromeDevTools. See it in action - ordering coffee. Learn more about this preview feature (available in Chrome Canary now): https://t.c
DI (依存性注入) って何のためにするのかわからない人向けに頑張って説明してみる - Qiita
追記 2022/11/12 追記 この記事読んで、DI 便利だなって思ったらこちらも併せて読んでみてください。クリーンアーキテクチャーの開設の中で依存性逆転の説明が出てきます。難しいかもしれませんが、一度理解すればつぶしが効く考え方なので腰を据えて読んでみてください。 本文 ここでは、最近のそこそこの規模のアプリだと大体使われてる（と私は思ってる）Dependency Injection（DI）について、何故使ってるのか？というのを私の理解で書いていきたいと思います。 今回の対象言語は C# ですが、DI 使ってる言語であれば大体同じ事情なのかなと思います。 単体テストしたいよね アプリケーションを作るとうまく動いているかテストをすると思います。 たとえ、そのアプリがハローワールドだとしても動かして目視で確認してると思います。 もうちょっとアプリの規模が大きくなってくるとクラス単位やクラス
テスト自動化とお掃除ロボット
テスト自動化チームでペアプロにトライした話 / trying to pair programming on test automation team
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
帰ってきたSelenium IDEはフロントエンドE2Eテストが気軽にできるあのSelenium IDEだった | そど
この記事は2017年11月21日に投稿した以下の記事の続きです。 Selenium IDEを失った僕たちはどこへ行くべきなのか (出題編) この記事の公開後、Web Extensions形式で実装された新しいSelenium IDEが2017年12月11日に 晴れて ver 1.0 としてリリース、その後も実装とバグ修正が進み 2018年2月27日 には ver 1.0.3 がリリースされました。中身の形式は変わってもブラウザ拡張なので簡単に導入出来ます。 Releases · SeleniumHQ/selenium-ide そして以下がその画面です（ver 1.0.3現在） なじみが有る感じのUIですね。まだまだ開発は初期段階との事ですが、実際に使ってみた所「出来ているのはガワだけ」なんてことは無く、実際に今までのテストケースを微修正しつつE2Eテストに活用していけそうなクオリティが感じ
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
Pythonで、unittest.mock.patchを使ってデコレータを差し替える - メモ的な思考的な
同僚と話している中で、unittest.mock.patchを使ったデコレータの差し替えに関する話題が出ました。 そういえばデコレータは差し替えたことがなかったため、試してみたことをメモします。 なお、「テストファイル群に、デコレータを差し替える/差し替えないものが混在している場合」で使った方法は強引な気がします。そのため、もしより良い方法をご存じであればご指摘ください。 目次 環境 用意したデコレータとプロダクションコード 引数なしのデコレータを差し替える 引数ありのデコレータを差し替える ダミー処理をするデコレータに差し替える デコレータの差し替え有無が混在する複数のテストファイルを同時に実行する場合 ソースコード 環境 Python 3.6.1 pytest 3.0.7 テストランナーとして使用 用意したデコレータとプロダクションコード デコレータとは、関数に処理を追加するためのシン
Testing Applications with WebTest — WebTest 2.0.31.dev0 documentation
What This Does¶ WebTest helps you test your WSGI-based web applications. This can be any application that has a WSGI interface, including an application written in a framework that supports WSGI (which includes most actively developed Python web frameworks -- almost anything that even nominally supports WSGI should be testable). With this you can test your web applications without starting an HTTP
たった1人から始める社内テストコード文化
# -*- coding: utf-8 -*- from __future__ import absolute_import, unicode_literals # テストする関数 def add(a, b): return a + b # テストコード 関数名はtest_ から始めるのがpytestでのお作法 def test_add(): assert add(1, 1) == 2 assert add(1, 2) != 2 >>> $ py.test ../tests/test_add.py =============================================================================== test session starts ================================================
UIテスト自動化でSIerのExcelスクショは滅びるのか - てんてんのぶろぐ
先日 JJUG CCC 2016 Fall に参加してきたってブログに書いたとおり、JJUG CCC 2016 Fallに参加してきました。 直接セッションは聞いていないのですが、 @backpaper0さんの 「Selenideを試行錯誤しながら実践するブラウザ自動テスト」というセッション中に流れてきたツイートがきっかけでタイトルの内容について考えてみたので書いてみます。 @backpaper0 さんの当日の資料は以下になります。 Selenideを試行錯誤しながら実践するブラウザ自動テスト 考えるきっかけになったのは、@khasunuma さんの以下ツイート。 @khasunumaさんは同イベントで Payara Micro の設計と実装 という発表をしています。Payara Microを利用している人には有用な情報が目白押しなので、見ることをオススメします。 Selenide導入した
フリーエンジニアのIT案件ならレバテックフリーランス
2016年11月3日（祝）、大田区産業プラザPiOにて開催された国内最大のPHPイベント「PHPカンファレンス2016」。レバテックフリーランスでは、カンファレンスセッションの登壇者のひとり・和田卓人氏にインタビューを実施しました。 テスト駆動開発の先駆者として知られる和田氏ですが、今回の講演テーマは「PHP7で堅牢なコードを書く-例外処理、表明プログラミング、契約による設計」。あえてテスト以外のテーマを設定した理由をはじめ、PHPの優位性や今注目している言語、初心者エンジニアへのアドバイスなど、幅広くお話を伺ってきました。 ＜この記事の要約＞ 1. PHPの良い点は、ゆるふわな言語に見せかけて堅牢なコードも書けるところ。悪い点は、覚えることが多くて難しいところ。 2. テストを書いていればコードの品質が高いわけではない。また、テストが書けないくらい問題を抱えたコードでも、中から改善してい
Tsungで負荷テストしよう(1) - 基礎知識
こんにちは。CTOの馬場です。 負荷テストツール Tsung の話です。 HTTP負荷テストツールだと JMeter や ab 、httperfあたりが有名ですね。 新しいところだとTsungやGatlingでしょうか。 私は去年くらいからTsungをよく使っているので紹介します。 このエントリは第1回です。 Tsungで負荷テストしよう(1) - 基礎知識 Tsungで負荷テストしよう(2) - 実践Tips Tsungで負荷テストしよう(3) - リアルな負荷のためのTips Tsung のお勧めポイント まずはTsungのお勧めポイントから。 負荷をかける側に必要なマシンスペックが低い 負荷をかけるとき、JMeterよりTsungのほうが同じサーバでより大きな負荷を生成することができます。 もちろん必要な負荷が1台で生成しきれない場合は複数台で連動して負荷を生成することができます。
ディープラーニングで簡単に自動テストスクリプトが作れる「Magic Pod」 | 品質向上ブログ
今日は、今話題のAI(人工知能)技術「ディープラーニング」を使い、誰でも簡単にモバイルアプリの画面自動テストスクリプトが作成できるWebサービスのお話です。 ※2017年7月24日よりオープンβ版を提供開始しました！ AppiumやSeleniumのような画面を自動操作するテストツールはとても便利ですが、一方で、こうしたツールを利用していないプロジェクトもたくさんあります。何がツールの導入を妨げているのでしょう? 筆者は、次の2つがとりわけ大きな問題だと考えています。 システムの内部情報をある程度理解しないと、テストスクリプトを書くこと・読むこと・編集することが難しく、それなりのスキルが必要。 テストスクリプトの作成に時間がかかりすぎる。特に、読みやすく変更に強いスクリプトを作成しようとすると、かなりの手間がかかる。 これらの問題を、ディープラーニングによる画像認識を使って解決しようとして
「現在時刻」を外部入力とする設計と、その実装のこと - クックパッド開発者ブログ
こんにちは。技術部 開発基盤グループの諸橋です。 クックパッドでは昨今の多くのWeb企業と同じように、GitHub EnterpriseのPull Requestを使ったコードレビューを広範に実施しています。わたしたちのコードレビューでは、ソースコードの字面にとどまらず、サービスの機能として魅力的かどうかや、保守性を含めた設計が適切かといった議論に発展することも良くあります。 きょうはそんななかで話題に上がった「現在時刻」の扱いかたに関する設計の話を書きます。 背景 サービスを開発・運営している我々には、時間帯によって出し分けたり、特定の期間のみに表示したいコンテンツがたくさんあります。 そのたびにデプロイし直すというのはつらいので(特に24:00に出なくなるコンテンツなど)なんとかしたくなりますが、一方で時限式のコンテンツはその時になるまでちゃんと動いているか確証が取れないので怖いです。
テストなんか書かなくて良い 僕の考えるサービス開発の肝 - mosa_siru’s blog
世の中は一周まわってエンジニアリングの手法に溢れている。 テストを書け、ドキュメントを書いて冗長化しろ、コミットはわかりやすく、コーディング規約が、安定性が─── でも、それって本質なんだろうか？ 新規サービスを作る際に肝だと思っていることをまとめてみた。 おことわり 以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定していません。 基本的に一通り現場をこなした中級以上のエンジニア向けに書いています。 アンチテーゼとして、ややキツめに断定する箇所が多いです、こういう意見もあるんだな程度に受け止めてください。 所属する団体の意見とかは一切関係ありません。 目次 おことわり 目次 ユーザーのことだけ考える
Espresso | Android Developers
Use Espresso to write concise, beautiful, and reliable Android UI tests. The following code snippet shows an example of an Espresso test: @Test public void greeterSaysHello() { onView(withId(R.id.name_field)).perform(typeText("Steve")); onView(withId(R.id.greet_button)).perform(click()); onView(withText("Hello Steve!")).check(matches(isDisplayed())); } The core API is small, predictable, and easy
ビルドやテスト環境の自動化は、顧客の一声でつぶされてしまった～自動化の現場の真実（前編）。システムテスト自動化カンファレンス 2015
ビルドやテスト環境の自動化は、顧客の一声でつぶされてしまった～自動化の現場の真実（前編）。システムテスト自動化カンファレンス 2015 テスト自動化研究が主催するイベント「システムテスト自動化カンファレンス 2015」が、2015年12月13日に、六本木のヤフー株式会社で開催されました。 午前中に行われたセッション「自動家は見た～自動化の現場の真実～」には関西のコミュニティ「おいしが」のメンバーが登壇。テストを含む開発環境を自動化しようとしてきたエンジニアの、現場での苦悩と苦労をリアルに紹介しています。 その内容を前編、中編、後編の3本の記事にまとめました。この記事は前編です。 自動家（オートメータ）は見た！ 自動化の現場の真実。 「おいしが」の前川博志氏。 おいしがから来ました。グループ名にあんまり深い意味はありません。 自動化で発表される事例は、わりと恵まれた環境で、すごい能力を持って
NetBeans IDEでのJunitテストの記述
This tutorial needs a review. You can edit it in GitHub following these contribution guidelines. このチュートリアルでは、NetBeans IDEでJUnit単体テストを記述および実行するための基本情報を紹介します。アプリケーションのテストは開発サイクルに不可欠な部分であり、単体テストの記述および管理はソース・コード内の個々のメソッドが正しく動作することを確実にするために役立ちます。JUnit単体テスト・フレームワークに対するIDEの統合サポートにより、JUnitテストとテスト・スイートを迅速かつ容易に作成することができます。 このチュートリアルでは、Javaクラス・ライブラリ・プロジェクト用の、JUnit 3およびJUnit 4という単純な単体テストとテスト・スイートを作成します。チュートリア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - svanoort/pyresttest: Python Rest Testing
Shizuoka.py #6 WebTestでWeb APIのテスト & Pythonメタプログラミングでテストの自動生成