Seleniumのテスト結果レポートをもっとおしゃれに | 品質向上ブログ
今日は、JUnitなどから実行したSeleniumテスト結果を、Allure Frameworkというオープンソースのレポートツールを使っておしゃれに表示する方法を、そのインストール手順とともにご紹介します。 目次 Allure Frameworkとは インストール(Eclipse + JUnit4 + Maven) Jenkinsとの連携 Allure Frameworkとは Allure Frameworkは、JUnit、RSpec、PHPUnit、Cucumberなど様々なテストフレームワークのテスト実行結果を、リッチなHTML形式のレポートで確認できるフレームワークです。 こんなレポートや、 こんなレポート、 こんなレポートが出力できます。 Seleniumを使わないユニットテストにも利用できます。レポートをJenkins上で表示することも可能です。 Allure Framewor
Django でフィクスチャのメモ - 牌語備忘録 -pygo
(python2.7, django1.5) モデルに初期データを投入する — Django 1.4 documentation settings.py 追加 FIXTURE_DIRS = ( os.path.join(ROOT, 'fixtures'), ) フィクスチャ作る fixtures/hoge.json ./manage.py shell とかでデータをいくつか作ってから、ダンプ出力したものを参考にするといいかも。 dumpdata ./manage.py dumpdata --format=json --indent=4 > fixtures/sample.json 読み込む loaddata ./manage.py loaddata fixture/hoge.json syncdb時に初期化して読み込む フィクスチャのファイル名を initial_data.json にすれ
気になってたSpockを試してみた - No Programming, No Life
Groovy!（挨拶） はじめに SpockはGroovy製のBDDフレームワークです。前から気になっていた*1ので是非試してみたいなと思っていたら、 id:backpaper0 さんが はじめてのSpock - 裏紙 で試していたので、私も試してみました。といってもやった内容はほぼコピペ。いわゆる手抜きってやつです。 試してみる とりあえず、わざと失敗してみる (worldの!がない) @Grab('org.spockframework:spock-core:0.5-groovy-1.7') import spock.lang.* class HelloSpec extends Specification { def '名前を呼んで挨拶する'() { expect: say(name) == message where: name | message 'world' | 'Hello,
PhantomJSとJasmineで振る舞い駆動開発なJavaScriptテスト
PhantomJSとJasmineで振る舞い駆動開発なJavaScriptテスト：フレームワークで実践！ JavaScriptテスト入門（2）（1/3 ページ） しっかりとJavaScriptをテストするために、今注目のJavaScript用のテストフレームワークをいくつか紹介し、その概要から実践的な使い方まで解説する連載 前回は、JavaScriptテストの基本、今回からフレーワムークを紹介 前回の「JavaScriptテストの基礎知識と使えるフレームワーク6選」では、JavaScriptのテストを取り巻く環境や、JavaScriptのテストに使用できるフレームワークの紹介を行いました。今回からは、前回の記事で紹介されたフレームワークを使用して実際にJavaScriptのテスト環境を構築し、テストを行うまでの流れを解説します。 今回は「PhantomJS」と「Jasmine」を取り上げま
JUnit実践入門 xUnitTestPatternsで学ぶユニットテスト
Team Foundation Server 2015 Update 2.1�アップグレード 手順書�～ Team Foundation Server 2...Masaki Takeda
TDDはYAGNIに矛盾する？ - カタチづくり
Joel on Softwareに面白そうな記事が載っていた。 とはいえ、どうも僕の英語力では完全な読解が難しい。会話を書き起こしたものなので当然ながら文体が会話調で、僕にはなかなか理解が難しいのだ。以下で僕の読み間違いがあれば指摘して欲しい。 さて、冒頭で Joel 氏はこう言っている。 Joel: There's a debate over Test Driven Development... should you have unit tests for everything, that kind of stuff... a lot of people write to me, after reading The Joel Test, to say, "You should have a 13th thing on here: Unit Testing, 100% unit tests
UWP を Continuum に完全対応させるには？ - 高橋 忍のブログ - MSDN Blogs
In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...
neue cc - Rx + MolesによるC#での次世代非同期モックテスト考察
最近、妙にテストブームです。Chaining Assertionを作ったからですね。ライブラリドリブンデベロップメント。とりあえずでも何か作って公開すると、その分野への情報収集熱に火がつくよね。そしてテスト厨へ。さて、ユニットテストで次に考えるべきは、モックの活用。C#でモックといえばMoqが評価高い。メソッドチェーンとExpression Treeを活かしたモック生成は、なるほど、良さそうです。読み方も可愛いしね。もっきゅ。もっきゅ。 というわけでスルーして(えー)Molesを使いましょう。Microsoft Research謹製のモックフレームワークです。PexとのセットはMSDN Subscriptionが必要ですが、MolesのみならばFreeです。VS Galleryに置かれているので、VSの拡張機能マネージャーからでも検索に引っかかります。 Moles。Pex and Mole
mixiエンジニアがおくるソーシャルアプリ開発実践講座：第3回 自動テストと継続的インテグレーションを既存プロジェクトへ導入しよう｜gihyo.jp … 技術評論社
はじめに はじめまして。（株）ミクシィの加藤和良です。2008年度に入社し、2011年1月からはシステム本部 技術部に所属しています。技術部は、日記やコミュニティといった特定のサービスに紐づかない、mixi全体を裏から支える部署です。「支える」ための方法は、実際のサービスの一部として動作する共通基盤から、開発効率を上げるために社内で動作しているものまで、多岐にわたります。 mixiでは、ここ数年で自動テストの導入が急速に進みました。図1は、mixiのソースツリーにおけるコードと、そのテストコードの毎月1日のバイト数をグラフにしたものです。2008年の頭には少なかったテストが急速に増え、今年の5月にはコード量をも追い越しているのがわかります。 携帯電話向けmixiである「mixiモバイル」の開始が2004年、mixiニュースが2006年ですから、2008年当時のmixiも、それなりに大き
品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
xUnit成熟度モデル 〜あなたの組織はどのレベル？ - 谷本 心 in せろ部屋
本エントリーは、Software Test ＆ Quality Advent Calendar 2011の10日目です。 http://atnd.org/events/22833 前の9日目は @m_seko さんの 「負荷テスト対象のWebアプリがこういう非機能要件(＋α)を備えていたらいいのにという願望」です。 http://d.hatena.ne.jp/sekom/20111209 普段、品質やテストなどには興味なさそう（？）にしている私ですが、 たまには、エンジニア視点から、テストについて語ってみましょう。 xUnit成熟度モデルって？ xUnit成熟度モデルとは、 組織がxUnitをより適切に利用できるようになることを目的として 遵守するべき指針を体系化したものである。 あわせて読みたい : 能力成熟度モデル統合 (CMMI) - Wikipedia 正味の話で言うと、僕がJUn
[NEWS] Visual Studio と NUnit が統合される - TDD.NET
それぞれの次期バージョンで、 親和性を高める計画が公表されています。 NUnit のファンも 単体の NUnit ランナーを見なくなる日が来るのかもしれません。 まず NUnit から。 近々 NUnit 3 にバージョンアップする予定になっていますが、 そのアーキテクチャ計画書 "NUnit 3.0 Architecture" (英文; 2011/02/19付け) を見ると、 IDE 統合の記述があります。 In the area of IDE integration, we will deliver a Visual Studio addin or package for running NUnit tests. ( IDE 統合の分野では、 NUnit のテストを実行するための Visual Studio のアドイン(またはパッケージ) を提供します。 ) 一方、 Visual St
![[NEWS] Visual Studio と NUnit が統合される - TDD.NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/bce7b4032f661a7a26d25348e039d8b1c32b9de1/height=288;version=1;width=512/http%3A%2F%2Fwww.tdd-net.jp%2Fimages%2F2011%2F07%2F11%2F20110711_vnext_unittestexplorer.png)
なぜUnitTestは理解されない？
TwitterでこんなTweetが流れた… エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに？ 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...） テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...） UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの ＝ テストコード テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使
テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる, tDiary 3.0.2 リリース - 会長@腹部日記(2011-04-29)
_ テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる まず、導入された結果は以下のようになっております。信じられないものもありますが、事実です。 1. マージが頻繁に行われる開発中はNoMethodErrorや文法エラーが続出。必要なコードのマージ漏れまで発生 2. 修正の度に人力テストが必要となり、コスト増大 3. これまで以上に責任論が追求される現場となる 4. コスト増加を恐れるあまりリファクタリングはおろか、巨大な迂回処理やコピペが横行する 本プロジェクトには、以下のようなテストコードを作(らない|れない)様々な原因があります。 問題分類 現場への影響
テストコードのリファクタリング - 千里霧中
ユニットテストの再利用や継続的利用を行おうとすると、テストコードにも保守性等に優れた良い設計が求められるようになります。そこで出番が増えてくるのがテストコードのリファクタリングです。 ただ現状、テストコードのリファクタリングはいくつか課題を抱えています。今回はその課題の１つである「リファクタリング前後でテストコードの振る舞いが変わっていないかチェックするテスト」（以下リファクタリングの回帰テスト）の実現方法についてまとめます。 テストの回帰テスト まずリファクタリングの回帰テストを真っ当に考えていきます。テストコードをテスト対象としてみると、一般的に以下の特徴が見えてきます。 SetupメソッドやMockオブジェクト等を通して、テスティングフレームワークから間接入力を受けます。 Assertionメソッド等を通して、テスティングフレームワークに対して間接出力を行っています。またMockオブ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Testable Lambda: Working Effectively with Legacy Lambda
ファイルを保存した瞬間ユニットテストを実行 - Qiita
https://github.com/yamkazu/spock-workshop/blob/master/docs/03_datadriven.md
https://aster.or.jp/business/testtool_wg/pdf/Testtool_beginningGuide_Version1.0.0.pdf
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
