You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
ヘッドレスChromeでシンプルに自動テストを行う Google Chromeのバージョン59から標準搭載された、ヘッドレスモード(GUIがないモード)。コマンドラインからヘッドレスブラウザを立ち上げることができ、スクリーンショットの撮影を行ったりDOMを出力したりすることができます。自動化の可能性に満ち溢れた機能です。 ヘッドレスChromeの導入については、次の公式ドキュメントが詳しいです。 ヘッドレス Chrome ことはじめ | Web | Google Developers ドキュメントを読んでいただくと分かると思いますが、様々なことが可能なため指示の記述が少し冗長な面があります。 そこでヘッドレスChromeを用いた自動化処理をシンプルにすることに特化した便利ツール「Chromeless」を紹介します。 なお、今回実装したソースコードはGitHubで公開しています。わせ
要約 ヘッドレス Chrome は Chrome 59 でリリースされています。これは、ヘッドレス環境で Chrome ブラウザを実行する方法です。つまり、Chrome なしで Chrome を実行することになります。Chromium と Blink レンダリング エンジンが提供する最新のウェブ プラットフォームのすべての機能をコマンドラインにもたらします。 なぜこれが有用なのでしょうか。 ヘッドレス ブラウザは、可視 UI シェルが必要ない自動テストやサーバー環境に最適なツールです。たとえば、実際のウェブページに対してテストを実行したり、その PDF を作成したり、ブラウザが URL をレンダリングする方法を確認したりできます。 ヘッドレスの開始(CLI) ヘッドレス モードを開始する最も簡単な方法は、コマンドラインから Chrome バイナリを開くことです。Chrome 59 以降がイ
console.log関連についてまとめました。 モダンブラウザであればどれも使用できると思いますが、基本出力結果等はchromeで確認したものです。 console.hogehogeのいろいろ console.log 基本 引数を入れることで出力結果をカスタマイズできます console.info、console.warn、console.error それぞれで見た目を変えることができます。 console.assert 式を評価してfalseの場合にログ出力します。 console.count ログの出力結果が同じ場合にカウント数が自動的に増えていきます。 console.dir オブジェクトのプロパティの中身をログに出力します。 console.dirxml HTMLとかXMLの要素を渡すと、下の要素が全部見れるようになります。 console.group、conosle.group
何年も前、SeleniumやWebDriverの話で盛り上がった記憶があります。ただ、その当時はまだRailsなどバックエンド中心の文脈でした。今、フロントエンドに軸足が移る中、ブラウザテストの状況はどうなったのでしょう? 不思議なことに、フロントエンド界隈でそれほど話題に上がって来ないですよね (私の周りだけ?)。結構大事なのに。実は皆さん、「Seleniumアレルギー」なんじゃないですか? 公式サイトに漂う ゼロ年代感(下図)。Javaへの躊躇、「めんどくさい」と聞かされ続けた過去、無意識に避けてしまうのがSeleniumです。 ただ、フロントエンドの文脈でこそ、ブラウザテストは重要度を増しています。そこで「Selenium触りたくない病」の筆者が、 四苦八苦した背景 と、2016年だからこそ 見えてきた落とし所 を書いてみたいと思います。 註: 思ったより長文になってしまいました。先
個人的に趣味で Chrome Extension の開発をしていますが、最近いろいろとノウハウも溜まってきたので Chrome Extension の CI について少しまとめてみようと思います。 目次 はじめに Chrome Extension のテストを書く 何をテストするのか テストフレームワーク Jasmine のインストール Jasmine でテストを書いてみる JavaScript APIs をモックする HTML Fixture を読み込む Chrome Extension のテストを実行する テストランナー Karma Karma のインストール Karma でテストを実行する ファイルの変更を監視する コードカバレッジを出力する HTML Fixture を読み込む Chrome Extension を CI する CI サービス Wercker Wercker にリポジ
ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript
テストを書く目的 自分の書いたコードが意図した通りに動いてるか確認するために書くのですが、自分が楽をするためと他の人のために書いてます。 自分が楽するため Webアプリの場合、実装した機能がちゃんと動作するかを確認するために何度もブラウザポチポチしてというのは時間がかかります。なのでその回数をなるべく減らすためにテストとして書けるところはなるべくテストで確認して、ブラウザポチポチする回数を必要最低限にしたいと思っています。 ブラウザポチポチするのも立派なテストだと思っています。再現性のない。 他の人のため テストがないと他の人がその機能に関連する機能を変更しようとした時に変更の影響がないのか確認することが出来ず、その機能に対するテストを手動で行わせてしまうことになってしまいます。 テスト書く時間がない問題 テストの話をすると書く時間がないと言われたりしますが、既存の開発の流れにテスト書くこ
FuncUnitって? WEBアプリケーションの単体テストフレームワークです. 公式ページ: FuncUnit 基本的にはjQuery風の記法でユーザのアクションを定義し,JavaScriptの単体テストフレームワーク QUnitでアサートするだけでユーザのアクション(テキスト入力,クリック,ドラッグアンドドロップなど)に対するアプリの動作をテストすることができます. なので,jQueryとQUnitを使ったことがある人であれば比較的簡単にテストコードを書くことができます.また,どちらも使ったことがなくても使う分にはそれほど難しいものでもないので,使ってみることをオススメします. 一回書けば延々ブラウザでポチポチする作業とはおさらばです. また,もう一つ重要な点としてコマンドラインからテストが実行できるという点です(実行中にFirefoxやIEが立ち上がったりしますが).ということはHud
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く