Loadroid gives you one-click access to a massively scalable, zero administration load testing platform. DevOps MindedLoadroid is designed to be a part of your DevOps workflow, Trigger load tests in each git push and build it in to your CI pipeline.
One framework for all platforms Mobile webTest on your web apps on real mobile devices, and scale easily by connecting to cloud grids Native mobileTest your native iOS and Android apps with Nightwatch Real desktop browsersTest on real browsers which accurately reflect your users’ environment Searching for bugs just got easy PinpointIdentify the source with the built-in HTML reporter with test stat
先日、日本Javaユーザグループ（JJUG）主催のJJUG CCC 2013 Fallで、「ユニットテスト改善ガイド」というタイトルで登壇してきました。自分の経験を元に、ユニットテストをチームや組織へ導入する時に起こりえる問題とその解決のヒントに関するセッションです。本エントリーではそのセッションの内容を再構成して公開します。 はじめに 近年のシステム開発では、ユニットテストや継続的インテグレーション（以下、CI）の導入は必要不可欠と考えられています。とはいえ、どんな組織（チーム）でも簡単に導入できているわけではありません。特に、大きな組織や古くからの慣習を残している組織では導入したくとも中々進まないと感じているところが多いのではないでしょうか？。 私は、これまでに多くの開発現場でユニットテストやCIの導入について推進してきました。成功したケースもあれば失敗したケースもあります。そして、失
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
先日書いた自分用アプリケーションのひな形 http://d.hatena.ne.jp/naoya/20130503/1367581629 http://d.hatena.ne.jp/naoya/20130504/1367640512 これに、JavaScript のテスト環境も追加したい。 結論からいくと、フレームワークには mocha + expect、ランナーは testem を使うことにした。ついでにテストダブルライブラリとして Sinon.js も有効にした。 ちなみに今回の文脈は End to End のテストではなくてユニットテスト周りのおはなしです。 mocha + expect JavaScript のこの辺のテスト周りは今もいろいろなツールの整備が進んでいて、今回採用した以外にも Jasmin や QUnit そのほか色んな物がある。昨今の状況に関しては 先日の HTML
Writing reliable JavaScript code at scale is difficult. The language lacks built-in formal structures that enable reliable engineering practices. Fortunately establishing convention and selecting mature libraries goes a long way towards building a trustworthy architecture. Furthermore writing unit tests gains confidence in our applications. In this first article in a series on unit testing JavaScr
Travis CIを始めとするウェブサービスとして使えるCIを使って、 JavaScriptのブラウザテスト(ブラウザ上でJavaScriptを走らせて行うユニットテスト)をやる方法をサービスごとにまとめてみました。 テストフレームワークとして Buster.JS を使用して行います。 Karma (旧Testacular) では公式サイトにも Karma – Travis CI でCI Serviceとの連携方法が記載されているのでそちらも参考にして下さい。 今回紹介するCI Servicesは以下のものです。 Travis CI drone.io BuildHive Jepso CI テスト実行の流れ Jepso CI を除いては、テスト実行の流れ自体は同じなので先に解説します。 Capture用のローカルサーバを立てる テストしたいブラウザで capture URL へアクセスする
日頃からJavascriptで開発をしているのにも関わらずあまりテストを書かないので、ここは本格的にテストを書こうと調べてみました。JavascriptのテストフレームワークといったらJsUnitなのかなーと思っていたが、調べてみると結構いろんな種類のテストフレームワークがあったりして、その中で得に人気なのかどうやらJasmineらしい。 Jasmine ～ JavaScript Test フレームワーク より引用: 今回は, JavaScript のテストを行うためのフレームワークJasmine の紹介です。 JavaScript のテストといえば, JSUnit が有名です。 JSUnit は, JUnit とに似たような, Matcher が利用できたりしてわかりやすいのですが, 開発やメンテナンスがストップしており, またWebプロジェクトに組み込まないと利用できないことが ちょっ
キーワードで探す カテゴリで探す トレンドを知る 事例を知る 展望を知る 技術ブログ サービスで探す コンサルティング CRM（Salesforce） ERP（SAP/Biz∫） 顧客接点・決済 カーボンニュートラル SCM・ロジスティクス 電子申請 データ＆インテリジェンス アプリケーション開発・管理 ブロックチェーン 量子コンピュータ・イジングマシン デジタルツイン IoT ロボティクス・RPA クラウド ネットワーク データセンター サイバーセキュリティ アウトソーシング 業種で探す 金融 官公庁・自治体 医療・ヘルスケア 防災・レジリエンス 食品 小売・流通 モビリティ 製薬・ライフサイエンス 食農・農業 製造 通信・放送 電力・ガス・水道 建設・不動産 個人のお客様向け 教育 トピックで探す Innovation Conference サステナビリティ キーワードで探す カテゴリ
JsTestDriverとphantomjsとJenkinsを使ってのJSの継続的なテストを行う方法を解説します。 Javaのインストール JsTestDriver、Jenkins共に実行にJavaが必要になるため、Javaのインストールを行いましょう。 すでにインストール済みの場合は必要ありません。 JsTestDriverのインストール JsTestDriverのjarを落としましょうダウンロードしたJsTestDriverを–portオプションで起動しましょう（ $ java -jar JsTestDriver[バージョン番号].jar –port 9876 ）設定ファイルのサンプルをダウンロードしてJsTestDriver.jarと同じディレクトリにJsTestDriver.confの名前で保存しましょうこれでJsTestDriver serverが起動します。 今回はテスト対象と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
