Serverspec と Infrataster でサーバのテストをする - rrreeeyyy.com
サーバの構築・運用の効率化の為に Test-Driven Infrastructure をする手法として、 Serverspec が登場して 1 年近く経ちました。 そして最近、Infrastructure Behavior Testing Framework として、 Infrataster が登場しました。 今日は、上記で紹介した 2 つを組み合わせて使用し、 実際にどのようにサーバのテストを行うかについて書きます。 書くこと・書かないこと - 書くこと Serverspec と Infrataster を両方使った Test-Driven Infrastructure の一手法に関して 今日書くのは、Serverspec と Infrataster を組み合わせることで、 Serverspec がカバーしている領域と Infrataster がカバーしている領域の両方をテストする一手
TDDという名の幻想... - Qiita
TDDは死んだ。テスティングよ栄えよ。 by DHH http://d.hatena.ne.jp/yach/20140424#p1 【翻訳】TDD is Fun http://diskogs.hatenablog.com/entry/2014/04/25/085112 を読んで思ったことをつらつらと書いてみます。 TDDはできれば、やったほうが良いのは確か？です。 しかし、実際の開発現場で全面的に採用するのは ミドルウェア等の画面の存在しないソフトの開発以外では ほとんどの場合、無益です。 なぜなら、TDDを採用すると開発時間が膨らむ、すなわち、開発コストが 膨らむからです。そして、ソフト開発では細かな仕様は変化していきます、 するとTDDではそれに合わせ、テストを修正していかなくてはなりません。 また、TDDで書かれたテストが全てのケースを抜けなく網羅できていること は稀です、抜けは必ず
TDDが死んだらしい - セカイノカタチ
実際には、より上位のテストを優先的に書こうという話。 http://d.hatena.ne.jp/yach/20140424 僕は以前から、ユニットテスト偏重なTDDの考え方に疑問を持ち、自分でテストを書くときは、なるべく上位のテストを書くようにしていました。 この考え方は、テストファーストな人達の評判が悪く、開発の方針を決める際に「なるべく大きな単位でテストを書くべきだ」という主張が通ることはほとんどありませんでした。 彼らの主張はこうです。 「ユニットテストを書け」「ターゲット以外はモック化しろ」。 そして、ときにはこの考え方が拡張されて、「ユニットテストを書きやすいようにクラスを設計しろ」となり(これは良いと思います)、「ユニットテストしにくいからコントローラーになるべくコードを書くな」とか言い出します。これは流石に本末転倒です。 こうして書かれたユニットテストというのは、開発者の思
【翻訳】TDD is Fun - diskogs's diary
@solnicが、DHHの例の記事へのカウンター的な記事をポストしてまして、自分のために読んでみたらよい内容だと思ったので、翻訳してみました。翻訳ミスとかあると思いますが、、、すみませんです。。。 TDD is Fun Posted by solnic on Apr 23 2014 著 solnic 2014年4月23日 Today DHH published a blog post about TDD being dead (to him at least). It’s really not that surprising since from what I know (please correct me if I’m wrong) David’s experience is mostly based on building web apps with Rails. I get that
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
PFIインターンへ行ってきた（前編）〜結合テストの自動化環境を整えてきた〜 - obfuscation’s blog
2011年3月1日〜3月31日の間、PFIインターンに行ってきた。本エントリは前編、後編にわけて書いてみようと思う。前編の今回はインターンの内容、インターンで開発した内容や設計、設計に至るプロセスやら私の成果について説明し、後編ではインターンのきっかけやインターンを実行する段階での私の心境、心構え、行動思想的な部分、環境適応やら震災云々について書こうと思う。 インターンの内容、その対象について説明し、どういう部分に悩みながら開発していったか紹介する（長いけど！）。最後に最終的な成果であるテストツールについて紹介し、社内でのインターン最終発表スライドで本エントリである前編を締める。 インターン内容 ミッション（テーマ）：PFIの製品である統合型検索エンジンSedueの結合テスト（機能テスト）を自動化すること テーマの決定については、PFIで需要のありそうなQA（品質保証）とテスト関連という分
「RSpec は英語として読みやすいから良い」というお題目はなんだったのか - @kyanny's blog
rspec-2.11 がリリースされましたね。いくつかの変更点の中に、今後は should ではなく expect を推奨し、デフォルトでは expect のみが有効化されるようになる、というものがありました。 http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax 個人的にこの変更は説得力に欠けるなーと思っていて、 expect 推しにする理由が should は Kernel にはえるので Kernel を include しない BasicObject のインスタンスに対して should を呼ぶとおかしくなる 標準ライブラリ delegate は Kernel のメソッドの一部だけを include するので rspec と delegate のどちらが先にロードされるかによって should の挙動
"rspec の書き方がわからない"
_ko1 @_ko1 やっぱり spec の書き方がわからない、のは理解が足りていないからだと思うんだが、書籍でも読むといいんだろか 2014-04-17 15:24:18
Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey
Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので読み返してみました。 Testing like the TSA by David of 37signals（TSAはTSAロックのTSAですね。RailsConf行く時に買った） 予想通り、DHHはなんでもかんでもテストを書くということに対してはだいぶ批判的なスタンス。 曰く、テストを書くということの裏側には、テストを書く時間、テストをアップデートする時間、テストコードを読んで理解する時間といったコストが発生しているので、テストを書くことによって得られるメリット（回避できる問題）とのバランスをよく考える必要がある、と。 議論を呼ぶことは承知のうえでDHHが提案する「Railsアプリのテストにおいて、やってはいけない7つのこと」は以下の通り。 100%の
ドキュメントの場所を知らせるために、落ちるテストを作る - $shibayu36->blog;
今回はドキュメントの場所をどうやって気づかせるかという話を書く。 ドキュメントがあるときの問題 以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;に書いたとおり、僕の意見としては 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う というものだった。 基本的には一番近いコメントにすると、見つけやすさ・更新しやすさともにある程度担保することが出来る。しかし、メインの部分が明確に決まらない*1いろんなパーツが関係しあう機能の場合は、ドキュメントを書かないと全体の概要が分からないということもある。このような時、ドキュメントを書いても結局そのドキュメントに気づかれないし、そのため更新されないとい
JenkinsとSelenium WebDriverでUI層のテストも自動化＆永続化する - プログラマでありたい
思い立ったようにJenkins特集をしておりますが、今回はJenkinsとSelenium WebDriverでUI層のテストの自動化をする話です。Seleniumは面倒臭い画面のテストを自動実行してくれるツールで、出てきてからもう７〜８年がたちます。Web系の開発に携わっている人であれば、一度は試したことがあるのではないでしょうか？そして、必ず挫折したことがあると思います。 その理由としては、せっかく作ったSeleniumのテストケースが腐ってくるからです。一般的にはUI層の変更は、ロジック層に比べて変化が激しいです。だからこそテスト自動化して保証することに意味があるのですが、そのテストケースを維持するのは大変です。そこで、Jenkinsの登場です。Jenkinsでサーバサイドで継続的に実行することにより、Seleniumのテストケースが成功を保てるようにします。また、複数のブラウザ・バ
テスト管理ツールを活用したテスト工程の効率化 ～（３）テストケースを再利用したテスト実施計画の作成 - Tech-Sketch
私たちは昨年、ソフトウエア開発プロジェクトのテスト工程の効率化に取組みました。効率化を実現するアプローチは多様ですが、今回の取組みでは、効率化可能なアクティビティを支援する即効性の高いツールを作成・適用する方針で進めました。実際に多くの開発プロジェクトが活用し、作業を効率化しています。この記事では、複数回に分けて私達の取組みと成果を紹介します。 前回 は、対象システムのライフサイクルに渡って維持・メンテナンスするべきテストケースのマスタ管理について説明しました。この回では「テストケースの選定とテスト実施スケジュールの設定」について説明します。(下図「実施テストケース選択」と「テスト実施者、予定日登録」の部分) ＰＪテスト計画を作成する テスト管理ツールでは、「ＰＪテスト計画」というプロジェクト的なものをユーザが定義し、その単位で実施テストケースやその予定／実績、発生不具合を管理します。ユー
Kiwi＋CocoaPodsで始めるiOSアプリの振る舞いテスト入門
Kiwi＋CocoaPodsで始めるiOSアプリの振る舞いテスト入門：iOSアプリ開発でもCI／継続的デリバリしようぜ（2）（1/4 ページ） 現代の開発現場において欠かせないCI／継続的デリバリを、iOSアプリ開発に適用するためのツールやノウハウを解説する連載。今回は、iOSアプリの機能の振る舞いをテストするテスティングフレームワークの特長とインストールの仕方、主な使い方を解説します。 前回の「iOSアプリ開発でCI／継続的デリバリ環境を始めるための4種の神器」では、CI／継続的デリバリ環境を構築するために必要なツール・サービスを紹介しました。 今回はiOSアプリのためのテスティングフレームワークの1つである「Kiwi（キウィ）」を使った振る舞いテストの書き方について解説します。 振る舞いをテストするテスティングフレームワーク「Kiwi」とは KiwiはiOSアプリケーションの機能の振る
Capybara-DSLのはなし - プログラマでありたい
ちょっとCapybaraについて、整理する必要があったのでこちらで簡単にまとめておきます。Capybaraは、Githubのスタートページに使い方が丁寧に書いているので、そちらを参照したら大抵のことが解るようになっています。 What is Capybara Capybaraは、Webアプリケーションのインテグレーション・テストを補助する為のライブラリです。Capybaraが提供する本質的な機能としては、DSLとDriverの2点のみです。DSLとはドメイン固有言語で、特定の問題に特化したコンピュータ言語です。Capybaraはテスティングフレームワークを操作する命令を、それぞれのフレームワークに依存しない形で提供します。つまり、テスティングフレームワークであるCucumberやRSpec,Test::Unitなどを透過的に利用できます。次にドライバーです。Webアプリケーションのインテグ
Mavenで一部のテストの実行/除外を切り替える - プログラミングメモ
やりたいこと 一部のテストは、普段(mvn test で実行したとき)は実行されないようにする。 ただし、mvn の引数で何かを指定すれば実行できるようにする。 また、そのテストは、NetBeansから「ファイルのテスト」で単独実行されるようにする。 使用した環境 NetBeans 7.4 Maven 3.0.5 (NetBeansにバンドルされていたもの) JUnitの@Categoryを使ってテストをグループ分け 「一部のテスト」には、JUnitの@Categoryでカテゴリを指定することで、他のテストと区別する。 Maven側では、特定のカテゴリのみテストを実行したり、テスト対象から除外したりできる。 カテゴリを指定するためには、カテゴリを表すマーカー用のクラスかインタフェースを作り、それをテストクラスに@Categoryを使って指定する。 マーカー用のインタフェースの例。インタフェ
Travis CI 入門：GitHub + Travis CI で継続的インテグレーション « をぶろぐ
1. Travis CI とはTravis CI はオープンソースコミュニティのためにホストされた CI（継続的インテグレーション）サービスです。 継続的インテグレーションってなんだ？ 継続的インテグレーション、CI（英: continuous integration）とは、主にプログラマーのアプリケーション作成時の品質改善や納期の短縮のための習慣のことである。エクストリーム・プログラミング (XP) のプラクティスの一つで、狭義にはビルドやテスト、インスペクションなどを継続的に実行していくことを意味する。特に、近年の開発においては、継続的インテグレーションをサポートするソフトウェアを使用することがある。 引用: 継続的インテグレーション - Wikipedia Travis CI は GitHub と連携しており、CI したいリポジトリーを接続しておくと、Travis CI がコミットを
NightWatch - node製のSeleniumクライアント
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました おお、これは表示系のテストが容易になりそう！ Seleniumは多数のブラウザを操作してテストを自動化できます。RubyやJavaなど様々なプログラミング言語向けにソース出力が可能で、各言語で作られたシステムと組み合わせることができます。 そんなSeleniumをnodeと組み合わせて使えるのがNightWatchです。書き方も使い方も柔軟で、これはテスト以外の用途でも活躍しそうです。 まずはテストの書き方。次のようなコードになります。 module.exports = { "Demo test Google" : function (client) { client .url("http://www.google.com") .waitForElementVisible("bod
JenkinsとSeleniumでJavaScriptのテスト自動化、最初の一歩。第1回 日本Seleniumユーザーコミュニティ勉強会
JenkinsとSeleniumでJavaScriptのテスト自動化、最初の一歩。第1回 日本Seleniumユーザーコミュニティ勉強会 1月18日に都内で開催された「第1回 日本Seleniumユーザーコミュニティ勉強会」。Seleniumプロジェクトの共同設立者であるJason Huggins氏による基調講演に続いて、有志によるライトニングトークが行われました。 本記事ではその中から、玉川紘子氏による「Jenkins x Selenium 最初の一歩」の内容を紹介します（追記：本記事のタイトルは「JenkinsとSeleniumでJavaScriptのテスト自動化」とありますが、実際の内容は「Selenium RCがJavaScriptの技術を用いて自動テストを行っている」という点がポイントという指摘がありましたので、ここに追記します）。 Jenkins x Selenium 最初の一
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェアテスト入門
【JaSST'14 Tokyo】システムテストの自動化による 大規模分散検索プラットフォームの 開発工程改善 #JaSST
