Rails Q＆A「Scaffoldで作成されるテストはそのまま使うべきか？」 - give IT a try
はじめに 先日、ソニックガーデンでインターンをやってもらっている学生さんから、Railsのテストに関する質問を受けました。 他のRails初心者さんにとっても役立ちそうな内容だったので、こちらで共有しておきます。 質問 現在学習している「RailsによるアジャイルWebアプリケーション開発」ではscaffoldを使ってアプリを作っていきます。 rails generate scaffold xxxをした際、specディレクトリ以下に自動的にRSpecのファイルが生成されます。 たとえば以下のようなファイルです。 疑問に思ったのは、これらをベースにして、足りないところを補うといった形で開発を進めていくのが正しいやり方なのでしょうか？ それとも、これらは削除して自分が必要だと思ったところだけを記述していけば良いのでしょうか？ 僕の回答 端的に答えるなら「これらは削除して自分が必要だと思ったとこ
RSpec をやめて Test::Unit に戻る - tmtms のメモ
最近の RSpec は、それまで obj.stub(hoge: value) と書けたものが、 allow(obj).to receive(:hoge).and_return value と書かないといけなくなったりとか、正気の沙汰とは思えないような変更をしたりするので、何年かぶりに Test::Unit を使ってみようとリハビリ中です。 RSpec は、テストケースを入れ子にできたり、テストケースや example がクラスやメソッドではなく、文字列で自由に書くことができたりしたのが良かったのですが、最近の Test::Unit ではそれもできるようになっています。 [ruby-list:48926] [ANN] test-unit 2.5.2 このリリースはとみたさんに使ってもらえるように改良したリリー スです。新しく追加した--locationはRSpecの--line_number
テストフレームワーク mocha - hokaccha memo
JavaScript Advent Calendar 2011 (Node.js/WebSocketsコース)3日目のhokacchaです。Node.jsのテストフレームワーク、mochaについて書きます。 mochaはTJが新しく作り始めているテストフレームワークです。ドキュメントを見ればできることは大体書いてありますので、ドキュメントを元にどういうことができるのかを解説していきます。現時点でのバージョンは0.2.0です。 http://visionmedia.github.com/mocha/ shouldについて まずmochaでどういうことができるかの前にshouldについて解説しておきます。mochaのドキュメントには特に説明もなくshouldが使われていて、shouldでどういうことができるかわかってないと、ドキュメントを読んだときにmochaの機能なのかshouldの機能なの
Stack Overflowのアーキテクチャ - ワザノバ | wazanova
http://www.youtube.com/watch?v=OGi8FT2j8hE1 comment | 0 pointsドイツのハンブルグで開催されたDeveloper Conference 2013で、Stack Overflowのアーキテクチャが紹介されてます。 Stack Overflowのネットワークは、110 Q&Aサイト、430万ユーザ、質問760万件、回答1360万件、月間5億6千万ページビュー サーバ25台: ウェブサーバ11台（内9台でほぼトラフィックさばく）、ロードバランサ1台 (+ 予備1台)、DBノード4台、アプリサーバ3台、検索サーバ3台（Elasticsearch）、Redisサーバ２台（キャッシュ、メッセージング） 毎秒質問が投稿されているので、トップページには都度最新の質問を掲載するように更新はできないが、ユーザの回答パターン、質問閲覧パターン、好みのタ
テスト考2014 - Hidden in Plain Sight
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く！テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く！テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI（Continuous Integration、継続的インテグレー
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
中年コーダーが教える本当にクリーンなコードの作り方 - 「リーダブルコード」の書評に代えて : 404 Blog Not Found
2012年09月18日15:00 カテゴリ書評/画評/品評Art 中年コーダーが教える本当にクリーンなコードの作り方 - 「リーダブルコード」の書評に代えて リーダブルコード Dustin Boswell / Trevor Foucher 須藤功平・ 角征典 訳 [原著:The Art of Readable Code] 遅まきながら出版社より献本御礼。 基本的に、以下のスライドを一冊の本にすると本書になる。 クリアなコードの作り方 - How to make clear code なのに「リーダブルコード」を読了した時の気持ちと、共訳者による以上のスライドを見た時の気持ちは180度違った。前者ではとても嬉しくなったのに、後者ではとても悲しくなったのだ。 なぜそうなったかを書くことで、本書に何が書かれているのかを紹介することにする。 クリアって cat /dev/null > dirty.
知っておきたいテストの“イロハ”（1）：ITpro
テストの基本的な知識は、あまねくITエンジニアが持つべきだ。しかし実際には、本当に基本的な知識でさえ浸透していないのが現状である。そこでこの記事では、ITエンジニアが最低限知っておくべきテストの基本知識と、その活用方法を解説する。 社会的なインフラとして構築された大規模システムで，大きな障害が多発している。こうした問題を防ぐためにも，高品質なシステムを開発する必要性がますます高まっていることは言うまでもないだろう。 システムの品質を向上させるためには，しっかりと設計を行い，それに基づいて正しく実装する必要があるのはもちろんだが，最終的にはシステムを動作させてテストするしかない。 テストで品質を検証するためには，周到なテスト計画やソフトウエアの特性に合わせたテスト設計，効率的なテスト管理が必須となる。そのためには，品質管理の担当者だけではなく，プロジェクト・マネジャーやリーダー，SEにも，テ
『JavaScriptのテスト手法』
みなさんはじめまして。 2011年11月に中途で入社し、現在はAmeba事業本部でスマートフォン版Ameba（通称デカグラフ）の開発をしている川口（facebook）と申します。 JavaScriptにおけるテストフレームワーク JavaScriptにおけるテストフレームワークとしては、有名なもので現在以下のものがあります。 ●JsUnit Javaのテストフレームワークとして有名な「JUnit」を参考に作られたテストフレームワークです。 ●QUnit もともとjQueryをテストするために開発されたフレームワークですが、現在ではjQueryへの依存が無くなっているためjQuery以外のライブラリを使ったプロジェクトでも使用できます。 ●Jasmine
mockito(とpowermock)でstaticメソッドの試験 - mokkouyou2001の日記
そんなこんなでかれこれ1年半位後回しにしちゃっていた、クラスメソッドのテストについて。 powermockを利用してテストする事とします。 http://code.google.com/p/powermock/ 以前のサンプル Mockitoの実験（モックを用いた単体テスト） - mokkouyou2001の日記 まぁ、題材は大体おんなじですというか流用です。 新しい部分としては、 計算結果に通貨記号を付与して返すメソッド追加。 （通貨記号はなぜかDaoのクラスメソッドとして実装されます） package logic; import dao.SettingsDao; public class CalcLogic { /** * 設定の税率で金額を求め、送料を付与して返す。 * * @param price * 金額 * @return 合計金額 */ public int calcPric
次世代のモックフレームワークであるJMockitの基本的な使い方 - 達人プログラマーを目指して
以前のモックフレームワークの技術的制約 今まで私が担当してきたプロジェクトにおいては、モックオブジェクトを使ったJUnitの単体試験はjMockとEasyMockのいずれかのフレームワークを利用して行ってきました。しかし、これらのフレームワークはJavaプラットフォームにおけるコード自動生成の考え方の変遷で説明したように動的プロキシーに基づいているため、以下のような制約がありました。 モック化する対象の型はインターフェースを実装しているか、継承可能なクラスであること モック化するメソッドはfinal、static、privateでないこと*1 モック化するロジックはコンストラクターの呼び出しではないこと モックオブジェクトをテスト対象クラスにDIかパラメーター経由で引き渡すことが可能であること モック化する場合はクラス全体をモック化する必要があること（getterやsetterなどは本物の
2010-10-03
Java開発環境（ユニットテスト編） - torutkのブログ で、Java開発環境（ユニットテスト編）として、ユニットテストで必須なモック作成のツールを紹介しました。このときは、staticメソッドを提供するクラスやfinalなクラスのモックが作成できないので、ツールを使ってモック作成を楽にするには、多少コーディング規約を緩めるしかないかと思っていました。上の日記では、JDaveというfinalを解除するツールを使ってfinalなクラスのモックを作るところまで記載していましたが、staticメソッドについては未解決のままでした。 その後、いくつかstaticメソッドを提供するクラスのモックを作るツールがあることを知ったので補足します。 PowerMock 前回紹介したEasyMockあるいはMockitoに、PowerMockを組み合わせると、finalなクラスのモック生成、static
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
