自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
Ruby: byebugからruby/debugへの移行ガイド（翻訳）｜TechRacho by BPS株式会社
新しいデバッガに乗り換えてデバッグプロセスを変更するのがつい億劫になることもあるでしょう。本記事によって、皆さんがruby/debugに親しんでスムーズに移行する助けになることを願っています。 以下、debugはruby/debugを指します。 免責事項 著者はdebugと比べてbyebugの経験があまりありません。不正確な情報や古い情報がありましたらぜひお知らせください。 本記事の目的は高度なレベルで比較を行うことです。debugの特定の利用方法については公式ドキュメントを参照してください。 本記事はすべての機能を網羅しているわけではありませんが、ほとんどの機能をカバーしているはずです。 🔗 debugを使うメリット 個別の機能を解説する前に、debugを使うメリットについて簡単に触れておきたいと思います。 1. 出力がカラー化されている 2. メソッドやブロックの引数をバックトレース
英国政府によるRailsアプリケーションテストの新標準（翻訳）｜TechRacho by BPS株式会社
概要 Open Government Licenceに基づいて翻訳・公開いたします。 英語記事: A new standard of testing for GOV.UK - Technology in government 著者: Ben Thorner、Peter Hartshorn -- 英国GDS（Government Digital Service）所属の開発者です 原文公開日: 2021/10/08 サイト: GOV.UK blogs 日本語タイトルは内容に即したものにしました。GOV.UKのRFCは以下で公開されています。 GOV.UKには、アプリに加えた変更をテストするという強靭な文化が根付いています。私たちは多くの場合、変更を加える前に（テスト駆動開発に沿って）テストを書き、変更をデプロイする前に（回帰テストに沿って）既存のテストがすべてパスする必要があります。 GOV.
テスト自動化研究会 - テスト自動化の8原則
1. 手動テストはなくならない 2. 手動でおこなって効果のないテストを自動化しても無駄である 3. 自動テストは書いたことしかテストしない 4. テスト自動化の効用はコスト削減だけではない 5. 自動テストシステムの開発は継続的におこなうものである 6. 自動化検討はプロジェクト初期から 7. 自動テストで新種のバグが見つかることは稀である 8. テスト結果分析という新たなタスクが生まれる これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら＝原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。 解説 1. 手動テストはなくならない ユーザビリティテ
スタブとモックの違い - Qiita
オブジェクト指向設計実践入門を読んで学んだことのまとめです。 具体的にRspecでモックを書くときはこうしましょう、といった具体的な話ではなく言葉の意味の説明がメインです。 ソフトウェアテストの対象 スタブもモックもテストコード内で使うものです。違いを考える前に、テストについて振り返ってみます。 テストを行うべきなのは、次の2つについてです。 オブジェクトがほかのオブジェクトからメッセージを受け取ったとき、期待する答えを返すことができるか 要するにパブリックメソッドに対するユニットテスト 「オブジェクト指向設計実践ガイド」には、プライベートメソッドに対するテストは書くべきではない、さらにいうとプライベートメソッドを書くべきではない(プライベートメソッドを他のオブジェクトに切り出して注入せよ)とあります。 オブジェクトが副作用のあるメッセージ送信を行うとき、その回数や引数が適切か ログを書く
時間がない時のテスト項目書の作り方 - Qiita
開発期間が短いプロジェクトでも、しっかり試験を行うには プログラムの品質を高めるには、試験工程でどれだけ良いテストを行ったかも鍵になります。 試験工程で良いテストを行うには、良いテスト項目書が必要です。 開発期間の短いプロジェクトでは、試験工程になかなか時間を割けないものですが それでも、短い時間で良いテスト項目書を作成する方法を……まずは自分のやってきたことを以下に纏めてみます。 時間がない時にまずやること 以下の作業を通し、テスト対象となるシステムを理解します。 要件定義を機能ごとに理解する 業務フローを、要件定義を意識しながら理解する 設計書を、要件定義・業務フローを意識しながら理解する 画面項目を、要件定義・業務フロー・設計書を意識しながら理解する DB項目を、要件定義・業務フロー・設計書・画面定義を意識しながら理解する 2.の業務フローの理解の時点で要件定義と合わない箇所を見つけ
市場バグを引き起こした優秀なデータたち - ボドゲを愛するテスト屋さん
※この記事は「ソフトウェアテストの小ネタ Advent Calendar 2017 - Qiita」用の記事です。 ソフトウェアテストの小ネタ 2日目担当のオムそばです。 実はちゃんとした(?)記事を書くのはこれが初めてなので、生暖かい目で見ていただければ。 そんなわけで早速表題の件、市場バグを引き起こした優秀なデータたちをご紹介します。 今回は、よくある「半角記号」、「空白やスペース」などは割愛させていただきます。 (2017/12/26追記)"市場バグ"という言葉に違和感や疑問を持たれた方は、こちらの記事をどうぞ。文言について整理してみました。 ■日時に関するデータ ・1969/12/31、2038/1/20：UNIX系のシステムに有効なデータ。UNIXのシステム時刻は1970/1/1 開始なので、それ以前のデータを打ち込むと予期せぬエラーが発生する可能性がある。また、同様に2038/
.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
「Serverspec」を使ってサーバー環境を自動テストしよう | さくらのナレッジ
ChefやPuppet、Vagrantといったサーバーの設定を自動で行うツールが普及しつつあるが、それと同時にサーバーの自動テストについても注目されるようになっている。今回はサーバーの自動テストを実現するツール「Serverspec」をLinux環境で利用する手順を紹介する。 サーバーの自動テストの必要性とテスト駆動開発 最近ではサーバーの設定やソフトウェアのインストールといった作業を自動で行えるツールが注目されている。しかし、設定後のテストについてはあまり注目されておらず、各種設定やソフトウェアのインストールが正しく行われているかどうかは手作業で確認することが一般的だった。しかし、手作業での確認にはミスや抜けが発生する可能性があり、また対象とするサーバーの数が増えるとそれに比例して手間も増えてしまう。そこで活用したいのが、サーバーの自動テストツールだ。 サーバーの自動テストツールは、あら
入門ガイド — 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 は，各テストを異なるオブジェクト上で実行することによって
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
古めの組織に導入する自動テスト・アンチパターン集 - 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の使い方 - Qiita
テストクラスを書くときに使いそうなので事前に調査した。 調べたのは下記の通り Springを使ってるのでDIしている箇所がモックにできるか staticメソッドの戻りもモックにできるか new Date()...の戻り値もモックにできるか 結論：できた。 これ1つで全部まかなえたのは結構大きいかもしれない。できないことはなんだろうか？？ package com.hachiyae.jmockit; import mockit.Expectations; import mockit.Mock; import mockit.MockUp; import org.junit.Test; import java.util.Calendar; import java.util.Date; import static org.hamcrest.core.Is.is; import static org.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Redirecting...
ネット上では、COVERAGEなどの環境変数を設定して rake spec を実行する方法で simplecov 走らせる手段が散見してるが、それはそれで面倒なので、simplecov 用の rake タスクを作成しました。 「RAILS_ROOT/lib/tasks/spec.rake」としてファイルを配置して「rake spec:scov」で実行可能。
RailsのSimpleCovでカバレッジレポートが出力されない場合の対処法 - Qiita
