ユーザーが使うように操作をすれば一連の内容がそのままテストシナリオに。非エンジニアや入社まもないメンバーもすぐにテストを作り始めることができるのでテスト自動化をスケールさせられます 詳細ページへ
![Autify(オーティファイ), AIを用いたソフトウェアテスト自動化プラットフォーム - Autify(オーティファイ)](https://cdn-ak-scissors.b.st-hatena.com/image/square/bd89af7cb9da4c85ede6b683dadadd514f6e6a70/height=288;version=1;width=512/https%3A%2F%2Fautify.com%2Fog_web_ja.png)
ユーザーが使うように操作をすれば一連の内容がそのままテストシナリオに。非エンジニアや入社まもないメンバーもすぐにテストを作り始めることができるのでテスト自動化をスケールさせられます 詳細ページへ
Static vs Unit vs Integration vs E2E Testing for Frontend AppsJune 3rd, 2021 — 13 min read In my interview "Testing Practices with J.B. Rainsberger" available on TestingJavaScript.com he gave me a metaphor I really like. He said: You can throw paint against the wall and eventually you might get most of the wall, but until you go up to the wall with a brush, you'll never get the corners. 🖌️ I love
2016-02-19 追記 Laravel5.4がリリースされテスト周りの書き方が大きく変更されています。 この記事の内容だとLaravel5.4では動作させる事が出来ません。 時間が出来次第、この記事にLaravel5.4でも動作するように編集します。 (参考) - https://laravel.com/docs/5.4/testing - http://qiita.com/komatzz/items/1679373c86c252c5f49f この記事で伝えたい事 テストコードを書く事により得られるメリット テストコードを書く時上で必要な考え方 REST APIでの具体的なテストコードの書き方 仕事でLaravel 5.3を触る機会があったので今回のサンプルではLaravel 5.3を利用します。 とはいえテストコードの基本的な考え方は他の言語やフレームワークでもほぼ同じですので、他の
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした: 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
GitHubのスターは2016年7月30日調べ。ただし、登場年によるバイアスが激しいので、この件に関してはあまり参考にならないですね...。 E2Eテストツール Nightwatch 総合的なE2Eテストツール。WebDriver実装(独自)と、アサーションライブラリが一体となっているのが、使いやすいような使いにくいような。 http://nightwatchjs.org/ https://github.com/nightwatchjs/nightwatch 書き方はこんな感じ。 module.exports = { 'Demo test Google' : function (client) { client .url('http://www.google.com') .waitForElementVisible('body', 1000) .assert.title('Google')
JavascriptのテストはXHRがネック JavaScriptを書いていると、RESTサービスを利用してXHR(XMLHttpRequest)やjQuery.ajax経由で JSONのやり取りをする処理を実装することが多い。 こういった処理は以下の理由からテストが書きにくい。 1.サーバサイドの実装状況に依存する 2.非同期処理 JavaScriptを始めたばかりの時はjsUnitを使ってテストを書いていたのだが、 この2点はいつもネックになっていた。 QUnitとmockjaxでだいたい解決する 新しいテストフレームワークをいろいろと試してみた結果、jQueryのテストフレームワークQUnitと jQueryライブラリのmockjaxを使えば自分が書く実装の大部分が解決できることがわかった。 QUnitについては色々と日本語の情報があるのだが、mockjaxについては ほとんど見られ
サンプルということでindex.htmlにJavascriptも書いてしまいます。 単純にclick meというボタンを押すと、ajaxによりリクエストを飛ばして、mockjaxがインターセプトして返すレスポンスデータを表示するといった簡単なものです。 とても簡単なのでぜひやってみてください。 <!DOCTYPE HTML> <html lang="en-US"> <head> <meta charset="UTF-8"> <title>How to use mockjax</title> </head> <body> <input id="fire" type="button" value="click me!" /> <div id="content"> <div id='text'></div> <div id='message'></div> </div> <script src=
# coding: utf-8 include ActionDispatch::TestProcess FactoryGirl.define do factory :user do name { Faker::Name.name } avatar { fixture_file_upload Rails.root.join('path', 'to', 'avatar.png'), 'image/png' } end end っていう風にすると良い。 こうすることで、avatar.pngをアップロードした状態のUserを生成できる。 最初ActionDispatch::TestProcessをincludeし忘れてて、「なんで動かないんじゃこいつ」ってなってたので、多分他にも困ってる人いるんじゃないかなぁ。 と思ってたら↓こういうやり方もあるらしい。 How to: Use test fixt
Docker をいじって遊んでいる。 http://www.docker.io/ Docker は PaaS ベンダの DotCloud がその PaaS のバックエンドとして使っている (?) ミドルウェアを公開したもの。適当な条件の VM をポコポコ生み出してはテストや実際の運用に使うことができたりするもの。例えば「Ruby と Bundler が入っている VM」みたいなのを設定で作っておくと、後日何か Ruby でアプリケーションを動かしたいと思ったときにそのイメージをベースに VM を作ってデプロイしてやればすぐにアプリケーションが動き出す。そもそも PaaS がやっているのはそういう事で、それを汎用化したのが Docker。Travis CI のような、各言語ごとの実行環境が整った VM みたいなものに任意のコードを渡してビルドさせる、みたいなプラットフォームを作るのにも使える
ブラウザの画面テストを自動化するツール、Selenium。 大変便利なツールなのですが、Selenium RC、Selenium IDE、WebDriverなど色々な名前が出てきて、「なぜこんなややこしいことになっているんだろうか」と思ったことはありませんか? その理由を知るには、Seleniumの歴史について知る必要があります。 今回は、Seleniumの誕生から2013年5月現在に至るまでの歴史を振り返りながら、それぞれのツールがどのような位置付けのものなのか、見ていくことにしましょう。 ※ 歴史はいいからとりあえずSeleniumを使ってみたい、という方は、Selenium公式サイトからSelenium IDEをダウンロードすれば使えます。 Selenium Core Seleniumの原型は、米ThoughtWorks社で働いていたJason Huggins氏によって2004年に作
$ bundle install $ spork --bootstrap Using RSpec Bootstrapping /Users/fakestarbaby/Projects/rails/devfun/spec/spec_helper.rb. Done. Edit /Users/fakestarbaby/Projects/rails/devfun/spec/spec_helper.rb now with your favorite text editor and follow the instructions. require 'rubygems' require 'spork' #uncomment the following line to use spork with the debugger #require 'spork/ext/ruby-debug' Spork.pre
ランディングページは、1度作って完成ではない。A/Bテストなどを繰り返し、その効果を測定することで、初めてコンバージョン率の高いページを保つことができる。A/Bテストは過去にZen Startupでも紹介したが、売上アップや、ユーザー数アップに直接関わるので、学んでおいて損はないはずだ。 Webサイトの管理者なら、一度はランディングページのA/Bテストを行ったことがあるだろう。問題は、A/Bテストには終わりがないということだ。一通りテストを終えると、またスタート地点に戻り、新しいテストアイデアを考え出さなくてはならない。最も合理的な方法は、しかるべき計画を立て、段階を踏みながらA/Bテストを繰り返していくことだ。 ランディングページのA/Bテストを効果的に行うには、いったいページのどの部分をテストすればよいのか?そこで今回は、簡単で手軽にできるA/Bテストのアイデア23個をまとめてみたので
Python | 10:08わたしはプログラマーではありませんが、いくつかの仕事でテストコードを見たり書いたりすることがあったので、その過程で思ったことをメモとして残しておきます。コーディングとテストを分けて工数を言う癖をやめようどっちもコードを書くのだから分けて考える必要はないテストコードの重要性は理解しているけど、工数も厳しいし客がテストコードを書くことに工数を割くことを認めてくれない。ありがちな話ですが、それがテストを書かないことの根拠であるならば少し考え直しましょう。コーディングとテストを異なる工程と考えるのをやめてしまえばそんなことに悩む必要はなくなります。つまり、「テストを書きながらコーディングする」のです。だいたい、普段プログラムを書いているときだって手元で動かしながらものを作っているでしょう。それと同じことをプログラムを書いてやればいいだけです。客がテストを書かせてくれない
Instagram がどこに買収されたとかは他のニュースサイトにお任せして、Django アプリケーションを正攻法でスケールして "成功" してるのがとても興味深いです。現時点で Instagram Engineering で紹介されていることと TechCrunch にも掲載されたスライドから個人的なメモとしてまとめてみました。 Instagram の哲学は シンプルであること オペレーション負荷を最小化すること すべて装備 とのこと。 Instagram は以下の OSS, サービスで構築されているようです。 >>> OS / ホスティング Ubuntu Linux 11.04 を Amazon EC2 にホスティング。以前のバージョンは高トラフィックになると固まる問題があったようです。運用は 3 人。EC2 にホスティングしている理由は、調査結果によるものではなく、"まだ進化途中だか
継続的インテグレーション 最近では iOS アプリでも単体テストを使った継続的インテグレーションが注目されています。 iOS 開発の単体テストについては、このブログでも取り扱いました。 Xcode 4 からはじめる Unit Testing GHUnitとOCMockでUnit Test効率化 一般的な CI 環境についての説明は、以下の本から抜粋するとこんな感じです。 Jenkins 作者: John Ferguson Smart,Sky株式会社玉川竜司出版社/メーカー: オライリージャパン発売日: 2012/02/22メディア: 大型本購入: 12人 クリック: 299回この商品を含むブログ (26件) を見る デプロイメントに至るまでの開発プロセスをスムーズにし、バグの検出とフィックスを素早く行えるようにし…(略) では iOS 開発における現実的な CI 環境を考えていきましょう。
Asynchronous behaviour driven development for Node. There are two reasons why we might want asynchronous testing. The first, and obvious reason is that node.js is asynchronous, and therefore our tests should be. The second reason is to make tests which target I/O run much faster, by running them concurrently. Write some vows, execute them: $ vows test/* --spec Get the report, make sure you kept yo
When my WordPress plugin had only three users, it didn’t matter much if I broke it. By the time I reached 100,000 downloads, every new update made my palms sweat. My first goal for the WordPress Editorial Calendar was to make it do anything useful. I was new to JavaScript and PHP and didn’t really know what I could pull off. In a few days I had a proof of concept. In a few more I had a working ver
Alpaca-webkitはcapybara-webkitのwebkit_serverと通信を行ってPHPでwebkitブラウザを動作させるためのツールキットです。まだまだ鋭意製作中なのでがんがん変わりますがどういったことができるか、ということの説明をかいておきましょう。 Capybara-webkit Capybara-webkitはthoughtbot社が作成しているQtWebkitを利用してブラウザでのテストが行えるライブラリです。Capybara-webkit自体はrubyのライブラリとc++で書かれたQtWebkitのサーバーの二つが同梱されています。 このQtWebkitのサーバープログラムはソケット通信で内部のWebkitブラウザに指示を出しJavaScriptの実行や、HTMLの操作などなどが行えます。普通、PHPでこういったブラウザ関連のテストをする場合は現状Selen
Whether starting from scratch or rebuilding a rich ecosystem, get pipelines flowing with preconfigured environments for your language and a minimal syntax with up to 50% less YAML or JSON. language: python python: - "3.7" - "3.8" - "3.9" # Command to install dependencies install: - pip install -r requirements.txt - pip install pytest pytest-cov # Command to run tests script: - pytest --cov=./ test
Today Paul Campbell asked on Twitter about the possibility of having an automated testing scenario using WebStorm and Mocha. Although there’s nothing built in to WebStorm to support this, it’s actually very simple to setup. All we need are a few bits and pieces: - Mocha. A testing framework for node.js. I’ve been using it for some time and it’s quite decent. It’s from the same guys that have broug
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く