自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
テスト自動化研究会 - テスト自動化の8原則
1. 手動テストはなくならない 2. 手動でおこなって効果のないテストを自動化しても無駄である 3. 自動テストは書いたことしかテストしない 4. テスト自動化の効用はコスト削減だけではない 5. 自動テストシステムの開発は継続的におこなうものである 6. 自動化検討はプロジェクト初期から 7. 自動テストで新種のバグが見つかることは稀である 8. テスト結果分析という新たなタスクが生まれる これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら＝原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。 解説 1. 手動テストはなくならない ユーザビリティテ
時間がない時のテスト項目書の作り方 - Qiita
開発期間が短いプロジェクトでも、しっかり試験を行うには プログラムの品質を高めるには、試験工程でどれだけ良いテストを行ったかも鍵になります。 試験工程で良いテストを行うには、良いテスト項目書が必要です。 開発期間の短いプロジェクトでは、試験工程になかなか時間を割けないものですが それでも、短い時間で良いテスト項目書を作成する方法を……まずは自分のやってきたことを以下に纏めてみます。 時間がない時にまずやること 以下の作業を通し、テスト対象となるシステムを理解します。 要件定義を機能ごとに理解する 業務フローを、要件定義を意識しながら理解する 設計書を、要件定義・業務フローを意識しながら理解する 画面項目を、要件定義・業務フロー・設計書を意識しながら理解する DB項目を、要件定義・業務フロー・設計書・画面定義を意識しながら理解する 2.の業務フローの理解の時点で要件定義と合わない箇所を見つけ
.simplecov でSimpleCovの設定をスマートに - Hatena::Blog::toshiwo
SimpleCov を使ってcode coverageを取るときに spec_helper.rb にこんな感じで書いていた if ENV['COVERAGE'] # <= rake spec / rake coverage を分けたい派なので require "simplecov" SimpleCov.start :test_frameworks do add_filter "/vendor/bundle/" end end # 以下略 RSpec.configure do |config| # ここも略... end プログラムのroot pathに .simplecov という名前のファイルを作り、SimpleCov の設定部分を書いてしまうことが出来るようになっているらしい (ということに気付いた .simplecov SimpleCov.start :test_frameworks
Rails SimpleCovでカバレッジが上書きされないようにする - Qiita
RailsのテストのカバレッジにSimpleCovを使っています。 bundle exec rake test COVERAGE=trueを実行すると、ControllerやModelのテストが順番に実行されますが、coverage/index.htmlには一部の実行結果のみが残っていました。 具体的にはModelのテスト結果がControllerのテストで上書きされた状態です。 調べてみるとSimpleCov.command_nameをそれぞれ別の名前になるようにすればうまくマージされることがわかりました。 test_helper.rbに次のような設定を入れました。 : require 'simplecov' SimpleCov.start do add_filter "/test/" add_filter "/config/" SimpleCov.command_name "MiniT
Dockerで日本語対応のHeadless Chrome + puppeteerを立ち上げ
docker-composeで日本語対応のHeadless Chromeを「puppeteer」で操作する手順です。 🐡 Dockerfile日本語対応のChromeの入ったDockerfileは次のように記述します。 FROM ubuntu:latest MAINTAINER morizyun <@zyunnosuke> # For Japan RUN sed -i -E "s@http://(archive|security)\.ubuntu\.com/ubuntu/@http://ftp.jaist.ac.jp/pub/Linux/ubuntu/@g" /etc/apt/sources.list # Basic RUN apt-get update \ && apt-get install -y sudo curl wget zip unzip git nodejs npm fon
入門ガイド — Google Test ドキュメント日本語訳
はじめに：なぜ Google C++ Testing Frameworkを使うのか¶ Google C++ Testing Framework を上手に活用すれば，より良い C++ のテストを書くことができます． Linux，Windows，そして Mac，あなたが C++ のコードを書いているこれらの環境に関係なく Google Test を利用できます． では，優れたテストを書くにはどうすればよいのでしょうか？Google C++ Testing Framework は，どのように役立つのでしょうか？我々は次のように考えています： テストには， 独立性 と 再現性 が必要です．別のテストの結果に依存して成功したり失敗したりするテスト，をデバッグするのは非常に面倒な作業です．Google C++ Testing Framework は，各テストを異なるオブジェクト上で実行することによって
WebDriver について私が知っていること (2017 年版) - ひだまりソケットは壊れない
もともと Selenium 2.0 で導入された WebDriver ですが、単に 「WebDriver」 と言ってもいろいろなものを指すことがあり *1、WebDriver を初めて使おうとする人にはややこしい状況だと感じています。 (私は数か月前に WebDriver を使おうとして混乱しました。) というわけなので、私が調べた 「WebDriver とは何か」 を簡単にまとめておきます。 WebDriver とは何か WebDriver とは、ユーザーエージェント (web ブラウザ) を外部のソフトウェアから操作したり情報を取得したりできるようにするためのものです。 テストの自動実行などに便利ですね。 W3C WebDriver と Selenium WebDriver 冒頭で述べた通り、Selenium 2.0 の目玉機能として導入された WebDriver なのですが、現在は
2017年JavaScriptのテスト概論 | POSTD
本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを
JUnit API探訪：Assertクラス／assertThatメソッド - Diary of absj31
JUnitをより深く知っていこう。と言う事で本丸JUnitのクラスから幾つか機能を探訪していこうかと思います。 org.junit.Assertクラス Assert (JUnit API) 主なメソッドは以下の通り。 メソッド 説明 assertArrayEquals(arrays expected, arrays actual) 配列同士を比較、イコールである場合true assertEquals(Object expected, Object actual) オブジェクト同士を比較、イコールである場合true assertFalse(boolean condition) 条件がfalseである事を検証、falseの場合true assertNotNull(Object obj) オブジェクトがNullで無いことを検証、Nullでない場合true assertNotSame(Object
Seleniumで結合テスト - Qiita
はじめに 「テスト」はアプリケーション開発において非常に重要なものです。 テストが通らなければ、リリースすることは出来ません。 もちろん、テストを通す前にテストを書かなければなりませんが、テストを記述するのは、容易ではありません。 学生の頃に仲間とwebアプリケーションを作った際には挫折しました... 一口にテストと言っても、様々な物があります。 単体テスト 結合テスト (インテグレーションテスト) 機能テスト システムテスト 今回は結合テストについて書きたいと思います。 結合テストとは 単体テストで通ったモジュール（部品）を組み合わせて行うテスト 主にモジュール間の接続点（インターフェース）がうまく機能するかを確認する場合と、結合した状態で外部から見て一体として正しく機能するかを確認する場合がある。 (IT用語辞典より) らしいです。 いまいちぴんとこないかも知れませんが、具体的IDCF
古めの組織に導入する自動テスト・アンチパターン集 - Qiita
アジェンダ そもそも、なぜ自動テスト？ 自動テストと騒ぐと冷たい目で見られる事もあるという話 個人・組織としての失敗談と、その処方箋 書かないこと テストがないレガシーコードにテストを組み込む方法については、触れない そもそも、なぜ自動テスト？ 自動テストは、うまく導入すれば、プロダクト品質の担保とユーザへのデリバリー速度に大きく寄与することが分かっているため。 Web業界の先端が、自動テストの効能を体現してる たとえばこんなフロー テストコードを書く プロダクトコードを書く テストコード、プロダクトコードをコミットしてプルリクを出す プルリクをマージすると、CI環境がロジックのフルテスト、UIのフルテストを走らせる テストが全部通ったらそのまま自動的にデプロイする コンピュータに任せられることは全てコンピュータに テスト実施は単純作業なので、人間が実施しなくても良いようになっている 人間
テストコードのないプロジェクトにテストコードを導入した話 - Qiita
背景 現在私が参画しているプロジェクトは、プロダクトコードに対するテストコードがありません。 ※正確に言うと、ものによってはあるけど全体に対する割合で言うと0.5～1割程度だったので、ほぼないと言える状態。 そのため、 デッドコードが存在するプロダクトコード(品質) 責務が曖昧で長すぎるメソッド(品質) そもそもどこからも使われていないクラスの存在(品質) デグレ(品質) 保守対応(リファクタリング、業務影響のない軽微なバグの改修)の際のリグレッションテスト工数増大(コスト) テストコードを書かない文化 といったように様々な角度からの負がありました(挙げようと思えばもっとあるかも)。 目的 上記背景にある負を少しでも解消することを目的にテストコード導入推進を行います。 前提 言語：java テスティングFW：JUnit(色々検討した結果これに決定) CI：リリースブランチへマージのタイミン
Spring Boot - テスト時に読み込むDBを変更する - Qiita
Spring Bootでテストを走らせるときに、開発用・本番用とは違うDBに接続しないなど、設定を変えたい時があります。その場合のは設定方法について。 Test時には、設定ファイルの優先度が変わる MavenでもGradleでもいいんですが、例えばMavenを使っているならば、Springプロジェクトは以下のような構成になっているはずです。 /my/good/project ├── README.md ├── pon.xml └── src ├── main │ ├── com │ │ └── ... │ └── resources │ └── application.yml └── test ├── com │ └── ... └── resources └── application.yml
JMockit＋JaCoCo トラブルあれこれ - knjnameのブログ
JMockitはテストのために一部のクラスの定義を書き換えるライブラリ、JaCoCoはカバレッジ取得用のライブラリ、どちらも昨今のJava開発のユニットテストで（多分）よく使うものです。 JMockit: http://jmockit.github.io/index.html JaCoCo: http://www.eclemma.org/jacoco/ Antで両方を使ったサンプルプロジェクトも用意してみました。 （ライブラリダウンロードのためにはじめてIvyも使ってみた） https://github.com/knjname/jmockit-jacoco-javaagent-arg-order JMockitもJaCoCo、どちらもinstrumentationという仕組みを用いてその機能を実現しています。 http://docs.oracle.com/javase/8/docs/api
単体テスト実施時にテストのカバレッジを計測するツール：EclEmmaプラグイン - Accele Biz IT開発技術 調査報告書
テストのカバレッジとは、テスト対象となるソフトウェア全体のうち、テスト実施部分が占める割合のことである。 Eclipse、JUnit(S2JUnit4を含む)を使用してテストを実施する場合、EclEmmaプラグインを用いることで、テストのカバレッジを計測することができる。 今回は、EclEmmaプラグインのインストールと使い方について紹介する。 <インストール方法> Eclipseのメニューバーの[ヘルプ(H)]-[Eclipseマーケットプレース(M)...]を選択する。 表示されたダイアログの検索欄に「EclEmma」と入力し、【実行】ボタンを押す。 インストール対象の「EclEmma Java コード・カバレッジ」が表示されるので、【インストール】ボタンを押す。 下記ダイアログが表示される。変更の必要は無いので、【確認(C) >】ボタンを押す。 ライセンスのレビューが表示されるので、
Selenium何とかっていうツールがやたら色々あるのはどういうわけなのか | MagicPod Tech Blog | MagicPod: AIテスト自動化プラットフォーム
ブラウザの画面テストを自動化するツール、Selenium。 大変便利なツールなのですが、Selenium RC、Selenium IDE、WebDriverなど色々な名前が出てきて、「なぜこんなややこしいことになっているんだろうか」と思ったことはありませんか? その理由を知るには、Seleniumの歴史について知る必要があります。 今回は、Seleniumの誕生から2013年5月現在に至るまでの歴史を振り返りながら、それぞれのツールがどのような位置付けのものなのか、見ていくことにしましょう。 ※ 歴史はいいからとりあえずSeleniumを使ってみたい、という方は、Selenium公式サイトからSelenium IDEをダウンロードすれば使えます。 Selenium Core Seleniumの原型は、米ThoughtWorks社で働いていたJason Huggins氏によって2004年に作
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ネット上では、COVERAGEなどの環境変数を設定して rake spec を実行する方法で simplecov 走らせる手段が散見してるが、それはそれで面倒なので、simplecov 用の rake タスクを作成しました。 「RAILS_ROOT/lib/tasks/spec.rake」としてファイルを配置して「rake spec:scov」で実行可能。
RailsのSimpleCovでカバレッジレポートが出力されない場合の対処法 - Qiita
Sign in - Google Accounts
