結合テストと呼ぶのをやめた話 - asterisc
はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類（small / medium / large）に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを
Google、Dockerイメージに対するテスト自動化フレームワーク「Container Structure Tests」オープンソースで公開
Google、Dockerイメージに対するテスト自動化フレームワーク「Container Structure Tests」オープンソースで公開 Container Structure Testは、コンテナ内部でコマンドを実行することで正しい出力やエラーが帰ってくるかどうかや、コンテナ内部のファイルが正しく格納されているかなどの検証を実行できるフレームワークです。 具体的には下記のテストをサポートしていると説明されています。 Command Tests コンテナイメージ内部でコマンドを実行し、正しい出力やエラーが返ってくるかを検証する。 File Existence Tests コンテナイメージ内部に、あるファイルがファイルシステム内の適切な位置に存在しているかどうかを検証する。 File Content Tests コンテナイメージ内のファイルシステムにあるファイルのコンテンツとメタデータ
idやclassを使ってテストを書くのは、もはやアンチパターンである - Qiita
いきなり結論を書くと、idやclassはスタイルのためのものなので、テストでそれを使うのはやめましょう。そして、カスタムデータ属性を使いましょう。(idやclassはスタイルのためだけではないという意見はごもっともです！しかし、主にとしてスタイルに使われるということでご了承頂いて以下の駄文に付き合って頂けると幸いです🙇) 先に断っておくと主にreactについての話で、JSXを前提とします。(手法はReactに限りませんが理由は後述) 2020/03/23 追記 この記事は1年以上前に書かれた記事なのでテストフレームワークとしてenzymeを使っていますが、現時点ではTesting Libraryの使用をオススメします。data-testid に対応するクエリを備えています。 React Testing Library · Testing Library はじめに ご存知の通り、ロジックと
TextTestを使った承認テスト
承認テスト(Approval Testing)は、現在のコードの出力を、“承認済”バージョンのものと比較するテスト技術だ。承認済バージョンは、事前にテスト出力を調査して、その結果を承認することによって作成する。要件が変更された場合でも、承認済バージョンを再検討することで簡単に更新することができる。テキストベースのオープンソース機能ツールであるTextTestは、この承認テストをサポートする。 トレーナでソフトウェア開発者、アーキテクトのEmily Bache氏はEuropean Testing Conference 2017で、TextTestを使用した承認テストのワークショップを行なった。このカンファレンスに関してInfoQは，Q&Aや要約，記事を通じてお伝えしていく。 Bache氏のワークショップは、承認ベースのテストという概念を説明することから始まった。氏はまず、TextTesでテス
NightmareJS+Dockerによる環境非依存なUIテストの導入 - Alpaca技術ブログ
Alpacaで主にフロントエンドを担当している北山(@gamella, blog)です。 フロントエンドを開発していると、「ログインして、これをクリックしたら、この表示が行われていること」みたいなUIテストを環境非依存で簡単に行いたいと思うことがありますよね？僕はあります。 Alpacaでは開発にDockerを全面採用しているということもあり、最近ちょくちょく目にするNightmareJSをDocker上で動かして簡単にUIテストを導入できたので、その知見を共有したいとおもいます。 Nightmare まず、どうしてDockerを利用したいかということですがAlpacaでは、すべての機能をDocker上で動作させているため、それに倣っているいうこともありますがUIテストをローカルでもCircleCIでも、Dockerが動作する環境であればどこでもコードの改変なしで実施できるというのは大きな
JavaScriptのテストツール「testem」が素晴らしいぞ - Mach3.laBlog
この記事は賞味期限切れです。（更新から1年が経過しています） JavaScriptユニットテスト一年生の私が、Nettuts+ のチュートリアルで知ったテストツール 「testem」のお陰で大変捗ったので是非お勧めしたく、ここで紹介してみます。 testem ってなに testem via GitHub : airportyh/testem Unit testing in Javascript can be tedious and painful, but Testem makes it so easy that you will actually want to write tests. 要するに、面倒なJSのユニットテストをより快適にしてみんなでハッピーにテスト書こうよ！というツールです。 testem自体はnode.jsベースで動作し、Jasmine/QUnit/Mochaに対応して
分散テスト実行システムRRRSpecをリリースしました - クックパッド開発者ブログ
技術部アルバイトの鈴木(@draftcode)です。 クックパッドが内部向けに開発・運用を行ってきた、分散テスト実行システムRRRSpecをオープンソースとして公開しました。RRRSpecは時間のかかる自動テストを分散処理することで、全体のテスト時間の短縮を狙うアプリケーションです。現在クックパッドでは17000を超えるテスト項目があり、マシン一台でテストを実行すると完了まで数時間かかります。このテストを60並列程度の分散処理で行うことで、平均8分から9分程度で完了できるようになりました。また、Amazon EC2のスポットインスタンスを利用することにより、大幅なコスト削減も同時に達成しました。 https://github.com/cookpad/rrrspec 分散テスト実行とは アプリケーションが大きくなるにつれて、自動テストの数も大きくなっていきます。クックパッドでは、非常に多くの
ユニットテスト改善ガイド | DevelopersIO
先日、日本Javaユーザグループ（JJUG）主催のJJUG CCC 2013 Fallで、「ユニットテスト改善ガイド」というタイトルで登壇してきました。自分の経験を元に、ユニットテストをチームや組織へ導入する時に起こりえる問題とその解決のヒントに関するセッションです。本エントリーではそのセッションの内容を再構成して公開します。 はじめに 近年のシステム開発では、ユニットテストや継続的インテグレーション（以下、CI）の導入は必要不可欠と考えられています。とはいえ、どんな組織（チーム）でも簡単に導入できているわけではありません。特に、大きな組織や古くからの慣習を残している組織では導入したくとも中々進まないと感じているところが多いのではないでしょうか？。 私は、これまでに多くの開発現場でユニットテストやCIの導入について推進してきました。成功したケースもあれば失敗したケースもあります。そして、失
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く！テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く！テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI（Continuous Integration、継続的インテグレー
そろそろPower Assertについてひとこと言っておくか - ぐるぐる～
タイトルはもちろん釣りで・・・はない！ ちょっと真面目に、Power Assertについて意見を述べたいのです。 そもそもPower Assertって何？ てきとーに説明すると、 普通の比較演算子で普通にassert書けば、失敗時に各部分式の値を表示してくれる ようなものです。 Groovy製のテスティングフレームワークであるSpockがおそらく本家大本です((要出典。こういう系の発想は割と昔からあったし、Spock以前に実装例がありそうな気がする。そもそも、Spockは最初からPower Assert持ってたのかも調べないといけない。ちなみに、式木を弄ってAssertを組み立てる、というものであれば(PowerAssertよりも情報量は少なくなるものだけど)、自分の知る限りだと2009年6月にこんな記事があります。 http://themechanicalbride.blogspot.j
マイクロソフトがテストツール「BrowserSwarm」発表
テスト結果はInternet Explorer（IE）、Google Chrome、Firefox、Safari、OperaなどのWebブラウザのバージョンごとに合格率が表示される。テストに合格した項目と不合格だった項目は別々に参照でき、修正が必要な個所がすぐに分かるようになっている。 BrowserSwarmのプロジェクトは、jQueryライブラリの開発などに参加しているappendTo、クラウドベースのテスト用プラットフォームを提供するSauce Labs、マイクロソフトのInternet Explorer（IE）チームが協力して手掛けている。 IEチームは「質の高いフレームワークは現代のWebの基盤であるにもかかわらず、さまざまな端末やWebブラウザで横断的なテストができるリソースはあまり存在していなかった。BrowserSwarmでは相互運用性を備えたフレームワークの構築を支援する
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
Theoriesさんの可読性をなんとか - 日々常々
mike、mikeなるままに…: Spockで例外のテスト ということなので、いろふさん早くSpockについてブログ書いて下さい。 mike、mikeなるままに…: Spockで例外のテスト とか言われたのでTheoriesネタで書きます。 Theoriesさん？ JUnit実践入門 8章 パラメータ化テスト をご参照下さい。 JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus) 作者: 渡辺修司出版社/メーカー: 技術評論社発売日: 2012/11/21メディア: 単行本（ソフトカバー）購入: 14人 クリック: 273回この商品を含むブログ (68件) を見る ……ざっくり言うと、パラメータ化テストは「一つのテストメソッドにパラメータを与えて複数のテストをするもの」です。テストメソッドの引数に入ります。色々方法はあるんですけど、シンプルな形だと
Java EE6で単体テストや結合テストを自動化する方法について - 達人プログラマーを目指して
今週水曜日に、オラクル青山センターで行われたGlassfish Japanユーザーグループの勉強会でJava EE6のお話をさせていただきました。勉強会のスライドとビデオは以下のリンク先にあります。 Glassfish勉強会（JavaEE6について） View more presentations from Ryo Asai http://www.ustream.tv/recorded/16552906 今回は基本的に私がこのブログで書いてきたJava EE6関連の情報について紹介させていただきました。欲張って少し内容を詰め込み過ぎたところがあったかもしれませんが、Java EE6を使った単体試験や結合試験の自動化については、説明をスキップしてしまい、ちょっとわかりにくくなってしまいました。ここで、あらためてJava EE6上のアプリケーションのテスト自動化について簡単に補足させていただき
JUnit4 の @Test でも簡単にパフォーマンステストが出来た！！！ - 宇宙行きたい
今まで、パフォーマンスに注意しなきゃいけないところは テストに StopWatch stopWatch = new StopWatch(); List<Long> times = new ArrayList<Long>(); for(int i = 0 ; i < 100 ; i++){ stopWatch.reset(); stopWatch.start(); foo.bar(); //計測する処理 stopWatch.stop(); times.add(stopWatch.getTime()); } BigDecimal sum = new BigDecimal(0L); for(Long i : times){ sum = sum.add(new BigDecimal(i)); } Long average = sum.divide(new BigDecimal(times.size
転身・未経験からのテスト業務 — ありえるえりあ
●●●●転身・未経験からのテスト業務 ●●●「初めて」から学んだこと ●●はじめに わたしはまったくの未経験でこの業界に飛び込んでしまいました。 詳しい経緯は省くとして、この章では未知の世界をどうにかこうにか1年間綱渡りしてきた体験談を元に、過去と現在と未来に抱えている問題とその解決法について考察してゆきたいと思います。 むしろ考察というよりは悟ったこと・解ったことのレポートのようなもの、個人的な所感やつぶやきかもしれません。 お茶・コーヒー片手に気楽にお読みくだされば幸いです。どうぞよろしくお付き合い下さい。 ●●初心者時代 ●運命のふしぎ さて、"まったくの未経験"と冒頭に書きました。 前職はファストフード店です。無料の笑顔を振りまきつつ、ハンバーガーを作ったりポテトを揚げたりそれらをセットにして売ったりしていました。PCには趣味でそこそこ慣れ親しんではいたもののプログラミング経験は皆
開発者から見たテストの現場 — ありえるえりあ
●●●● 開発者から見たテストの現場 ●●● はじめに 私はアリエル・ネットワーク株式会社の開発部ソリューショングループに所属しています。ソリューショングループは、プロダクトグループが開発しているグループウェア「Ariel AirOne Enterprise」(以下AAE)上で動作するアドインの開発を担当する部署で、お客様から頂いた仕様を基に開発を行う、パッケージというよりは受託開発に近い仕事です。主な担当範囲はプロジェクト管理とアドインの実装で、いわゆるテストエンジニアではありません。とはいえ、ソフトウェア開発においてテストを避けて通ることはできません。この章では、ソリューショングループにおけるテストへの取り組みの変遷と、これまでに携わった実際のプロジェクトにおける試行錯誤の事例と教訓を開発者の視点から紹介したいと思います。 ●●● ソリューショングループ テストの変遷 ●● チーム発足
パッケージソフト開発のテスト体制 — ありえるえりあ
●●●● パッケージソフト開発のテスト体制 ●●● 前書き ●● はじめに 2001年4月、筆者は他の数人と一緒にアリエルネットワーク株式会社(以下アリエルネットワーク)を創業しました。創業以来、一貫してパッケージソフトウェアの開発を行っています。 パッケージソフトの開発を通じて製品の品質を上げるために様々な試行錯誤を行ってきました。本特集では開発の現場で行ってきた品質を上げる施策について、過去、現在、未来に分けて書きたいと思います。 ●●● 過去 ●● アリエルネットワークの成立ち アリエルネットワークは5人のメンバーで創業しました。5人のうち(筆者を含む)4人は現役のプログラマで残り1人の創業社長も元ソフトウェア技術者という開発者の集まりでした。そして5人全員が外資系ソフトウェア開発会社で働いた経歴を持っていました。外資系ソフトウェア会社もDEC、Lotus(IBM)、Microsof
大江戸Ruby会議01 高速なテストサイクルを回すには - 2nd life (移転しました)
本日大江戸*1で行われた大江戸Ruby会議01で、高速なテストサイクルを回すにはという内容で発表してきました。 大江戸Ruby会議01 高速なテストサイクルを回すには View more presentations from hotchpotch テストを速くするには二パターンあり、一つは単体実行時の速度・フィードバックの高速化、もう一つはすべてのテスト実行時の高速化があると思っていて、それらについての話です。ぎゅっとまとめると、前半の単体実行時の速度・フィードバック高速化には spork / prefetch-rspec / autotest / watchr を使おうという話と、後半は REE / parallel_tests による高速化・並列実行、remote spec によるリモートマシンでの分散テストについての話です。 特にオレオレプロジェクトの prefetch-rspec
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
レガシーコード改善の戦略と戦術
