Rubyのテスティングフレームワークの歴史（2014年版） - 2014-11-06 - ククログ
2014年12月にRuby 2.2がリリースされる予定です1。 Ruby 2.2にはRuby 1.9.1のときに外されたtest-unitというテスティングフレームワークが再びバンドルされる予定です。Rubyのテスティングフレームワーク周りに詳しくない人にはよくわからない状況でしょう。そこで、Rubyのテスティングフレームワークの歴史を説明することで状況を整理します。 名称の整理 この説明の中ではたくさんのテスティングフレームワークが登場します。似たようなものもあるため、最初にテスティングフレームワークの名称を整理します。この説明の中で登場する名称は次の通りです。 RubyUnit Lapidary rubyunit Test::Unit test/unit test-unit miniunit minitest RSpec 違いがわかりますか？ざっくり説明すると次の通りです。 RubyU
Ruby用単体テストフレームワークtest-unitでのデータ駆動テストの紹介 - 2013-01-23 - ククログ
test-unitはRuby用のxUnit系の単体テストフレームワークです。2.3.1からデータ駆動テスト機能が追加されていたのですが、2.5.3まではリファレンスに記述がなく、知る人ぞ知る機能でした。 2013-01-23にリリースされた2.5.4ではデータ駆動テスト機能についてのドキュメントが追加されています。 データ駆動テスト自体の説明はUxUを用いたデータ駆動テストの記述を参照してください。 Cucumberのscenario outlinesに似ていると言えばピンと来る人もいるのではないでしょうか。 Cucumberのscenario outlinesも前述のククログ記事の通り、テストのデータとロジックを分離しているのでデータ駆動テストの一種と言えます。 今回は、データ駆動テストを導入した例を見ながらtest-unitでのデータ駆動テスト機能の使い方を紹介します。なお、以降の説明
コミットへのコメントサービス - クリアコード
改良版サービスのおしらせ 現在は、本サービスの改良版を「コードリーダー育成支援」として提供しています。本サービスで大事にしていることはコードリーダー育成支援サービスでも同様に大事にしていますので、本サービスにご興味がありましたらお問い合わせください。開発チームにあった進め方をご提案します。トライアルを実施して理解を深めることもできます。 クリアコードは、よいコードを書くことを当たり前にするためには、まず「みんながみんなのコードを読む」文化にすることからはじめるのがよいと考えます。 そこでクリアコードは、「みんながみんなのコードを読む」文化づくりを支援する目的で、「コミットへのコメントサービス」を提供します。 みんながみんなのコードを読む文化とは みんながみんなのコードを読むとは ここでいう「みんな」とは同じ開発チームのメンバーのことです。「みんなのコードを読む」ということはコミットされたす
働く環境としてのクリアコード（福利厚生編） - 2013-05-16 - ククログ
はじめに クリアコードでは一緒に働くプログラマーを募集しています。昨年6月からパッチ採用という採用方法にしましたが、それ以来、採用へのお問合せがほとんどなくなりました。今年2月からインターンの募集を開始しましたが、まだお問合せがありません。しかし、採用やインターンシップページヘのアクセスは増加しています。採用ページを見た方がクリアコードは何か特別なスキルを要求しているように感じたり、パッチ採用のプロセスは時間や労力がかかりそうだがそれだけのコストを払う価値があるか判断できない、あるいはそもそも応募するかどうか判断するための情報が不足していることが原因ではないかと仮説をたてました。 実際、パッチ採用を開始する前の去年4月に入社した社員に聞いてみると、「いやあ、パッチ採用してなくても応募するのは敷居が高かったですよ。踏ん切りつけるのに1ヶ月ぐらいかかりました。面接して次はペアプログラミングと言
思い出せるチケットの書き方: 「動機」、「ゴール」、「実現案」 - 2012-07-12 - ククログ
ソフトウェア開発を支援するために、やりたいことや問題を管理するシステムがあります。例えば、Bugzilla1やRedmine2、GitHubなどがそのような機能を持っています。システムごとにやりたいことや問題の呼び方が違います。例えば、Bugzillaでは「バグ」、Redmineでは「チケット」、GitHubでは「Issue」と呼んでいます。ここではRedmineと同じ「チケット」と呼び方を使うことにします。 今回紹介するのは、後からチケットを見たときに、チケットを書いた時に知っていた情報を思い出せるようなチケットの書き方です。 このような書き方は、プロトタイプのような「作って終わり」とか「短期間の開発」というようなソフトウェアでは必要がないでしょう。また、後述の通り、「チケット駆動開発」にも使えないでしょう。継続的に開発を続けていくソフトウェアの開発のように、やりたいことや問題はあるけど
わかりやすいコミットメッセージの書き方 - 2013-04-24 - ククログ
もう1年以上前になりますが、コミットメッセージの書き方を説明しました。ざっくりまとめると、以下のことを説明しています。 わかりやすいコミットメッセージがいかに大切か どのようなコミットメッセージがわかりやすいか（具体例付き） この説明をしてからも、日々コミットしていくなかで新たに得られた「どうすればもっとわかりやすいコミットメッセージになるか」という知見が増えていました。これは、コミットへのコメントサービスの提供を開始した1ことも影響しています。このサービスでは、コミットへコメントするときに「どうして自分は他の書き方よりもこの書き方をわかりやすいと感じるか」を説明しています。その過程で「なんとなくこっちの方がよさそう」だったものを「具体的にこういうときにこう感じるのでこっちの方がよさそう」と何かしら理由を考えるようになりました。これにより、今までそれぞれの開発者でなんとなくだった考えが共有
groongaにデータを登録してからインデックスが更新されるまでの流れ - 2011-10-05 - ククログ
全文検索エンジンgroongaを囲む昼下がり@札幌はたっぷり3時間もあるので、「groongaがどのように動いているか」、「より効率的に検索するためにはどうしたらよいか」などといった話ができるはずです。 この文書は、札幌でのgroonga勉強会で使うための「groongaがどのように動いているか」を説明に使うための文書です。後でgroongaのドキュメントにマージする予定です。 それでは、groongaがどのように全文検索用のインデックスを作成しているかを説明します。まず、全文検索機能で重要なオブジェクトを説明して、その後にそれらを使ってどのようにインデックスを作成しているかを説明します。 主要オブジェクト groongaの全文検索機能で大事なオブジェクトは以下の3つです。 テーブル カラム トークナイザー それぞれ順に説明します。 テーブル groongaでは、ひとまとまりのデータを「レ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
