REPL と REPL 駆動開発について調べたメモです. REPL とは# Read-Eval-Print-Loop の略. 読んで、評価して、表示するを繰り返す. Read – eval – print loop - Wikipedia, the free encyclopedia 対話的に開発するためのツール. 素早いフィードバックを得ることで、頭に浮かんだ考えを即実行できる!! インタラクティブシェルとの違いがよくわからなかった. Lisp 系の言語で REPL という用語が利用され, スクリプト言語で インタラクティブシェルという用語が利用される?? インタラクティブシェル - Wiki programming languages - Difference between a REPL and interactive shell - Pro… 各言語のサポート状況# スクリプト言語
TDD/BDDにおける「振る舞い」の意味するところとは何なのか：いまさら聞けないTDD/BDD超入門（3）（1/3 ページ） 前回の「TDD／BDDの思想とテスティングフレームワークの関係を整理しよう」では、TDD／BDDについて、その思想と、それをサポートするテスティングフレームワークに分けて解説しました。その中で、TDD／BDDについては実際の熟練者の言葉を借り、テスティングフレームワークについては概要を触れて、その系譜をたどりました。 BDDはその名前に「Behavior」とありますが、「振る舞いとしてのテストコードを書く」とはどういうことなのでしょうか？ 難しく考え過ぎる必要はありませんが、「それは振る舞いを書いていないよ」と指摘をする熟練者が何を考えているかを理解することはBDDを習熟していく中で重要な意味を持ってきます。 本記事では「振る舞い」という言葉がどのような意味で使われ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 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を採用すると開発時間が膨らむ、
みなさんこんにちは。@ryuzeeです。 planetgeek.chというサイトでUrs Enzler氏がTDDのチートシートを公開していたのでご紹介します。 Clean Code and Clean TDD Cheat Sheets (PDFファイルでダウンロード可能です) 以下で、チートシート内の一部を意訳にてご紹介しましょう。 Unit Test Smellsテストが何もテストしていない一見するとテストが有効に機能しているように見えるが、実はテスト対象をテストしていない テストに過度なテスト準備が必要とされるテストが環境をセットアップするのに長いコードを必要としている。こういうノイズがテストが本当にテストしたいのが何なのか？ということを分かりにくくする。 大きすぎるテスト有用だが大きすぎるテスト。たぶんテストが１つではなく複数の機能をチェックしているか、テストが１つ以上のことをやろう
最近新人のコードレビューをする機会が増えまして、自分の中の経験則を言語化する機会に恵まれています。なんとなーくわかっていた事柄を人に伝えようとするのは、いつの時代にも最良の学びの機会ですね。 さて新人各位に個別に伝えた「JUnit4利用に関する注意」を整理してみました。JUnitは自由度の高いフレームワークであり使い方は十人十色かと思いますので、もっと良い使い道をご存知のかたは是非はてブコメントなどで教えていただければと思います。ちなみにここで言う「テスト」とは実装の前に書く単体テストだけではなく、実装後に書かれるものや自動化された統合テストも含めています。 １．JUnitを使うために押さえるべき前提知識 テストメソッドの実行される順番は不定 EclipseのJUnit実行機能に親しんでいると意外と気付けないのですが、JUnitはテストクラス内のテストメソッド実行順を保証していません。それ
でもそんなのどうでもいいから最終的には皆自分のTDDを持てばいいのではと思っている 2012-08-30 12:27:33 via web あなたがTDDだとおもうものがTDDです。 ただしたにんのどういをえられるとはかぎりません。 2012-08-30 12:30:20 via Twitter for iPhone ということで、TDDを定義します。 はじめに TDDを定義し、それの基礎を明らかにし、リファレンスモデルを明にする。 そして、他の例も紹介してみます。 TDDとは何であるか TDDとはソフトウェア開発者向けフレームワークです。 RED -> GREEN -> REFACTOR のスパイラルモデルが根幹にあります。 RED, GREEN, REFACTOR は開発者のアクティビティになります。 僕の理解ではプロセスの部分集合がフレームワークであるから、プロセスと呼ぶ事もできるけ
私がRSpec使ってテスト書く時はこんな感じで書いてるよ〜ってのを書いてみた。*1 テストを書く順番について TDDでコードを書く場合、先にテストを書く事になります。 そして、そのテストを書く順番ですが、私は下記のような順番で書くように意識しています。 設計する describe を書く itを書く subjectを明確にする before(context)を明確にする その他に、気をつけている点はこんな感じ 別のメソッド呼ぶ時は基本的にstubなどで潰す contextは「〜の場合」、it は「〜であること」になるようにする 一つずつ、詳細を書きます。 設計する テストを書き始める前に、まず実装しようとしてるクラス、メソッドを簡単に設計します。 少なくとも、「クラス名」「クラスメソッド or インスタンスメソッド」「メソッド名」「メソッドの戻り値」ぐらいは決めます。 describe を
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
Rails3.2 + RSpecで楽しいTDD(導入編)
さて、標題にはTDDと書いてますが実際にはコード書いてからテスト書いてたりしてます。 手元でちまちま書いてるアプリもさすがにテストも無しではいかんだろうということで まずは手元にあるコードのカバレッジが100%となるテストを書き、 その後次に何か乗っける時からはテストから書いていきたいと思います。 というわけで今回はテスト環境の導入編から。 この記事で前提とする環境は ・CentOS6 ・Ruby on Rails 3.2.2 ・Ruby 1.9.3 p-125 ・MySQL となっています。 (1)テストに必要なGemの導入 app_root/Gemfileに以下の記述を追加 gem 'rspec-rails' gem 'simplecov', :require => false #gem 'simplecov-rcov', :require => false gem 'spork' '
This document discusses an algorithm called FizzBuzz and includes links to articles about it. It also discusses using a Last Recently Used (LRU) cache to track recently accessed data and remove the least recently used items when the cache reaches capacity. Code examples are provided for implementing an LRU cache using a Map data structure.Read less
12. # calendar_test.rb require 'test/unit' require 'date' require './calendar' class CalendarTest < Test::Unit::TestCase def test_jan_first_day jan = Calendar.new(2011, 1) assert_equal Date.new(2011, 1, 1), jan.first_day end end 14. $ ruby calendar_test.rb <internal:lib/rubygems/custom_require>:29:in `require': no such file to load -- ./calendar (LoadError) from <internal:lib/rubygems/custom_requi
2012/04/06(金)はyujioramaさん主催のTDDカンファレンスでLTしてきました。 TDDBCなどで活躍されている皆さんに混じって発表するのは、少し気後れするところはありましたが、いい機会がいただけて良かったと思います。 発表に使ったスライドは↓↓。 ゆるLTのススメ+α View more presentations from joker1007 TDDは後々まで使えるテストを生んでくれますが、ベースは設計技法だと思ってます。 インターフェースを設計する力が無ければ、TDDを実践するのは不可能です。 そもそもできないものを書けるようにしてくれる魔法ではない。 一方で、ある程度やれるなら、ゆるくTDDを始めることで、段階的に設計力を身に付けることができるやり方だと思っています。 TDDの原則として掲げられていることと、厳格に一致しなくてもいい。 最初はコードを書いてから考えて
バージョン管理 セーブポイント 安心 CVS 2004年当時 昔は手で アナログ管理の限界 Linuxカーネルのプロジェクトがgithubに、膨大な人間が関わった時の管理のモデル scmbcもあるよ テスティング 安心の土台 自分が書いたコードをすぐに試す 自動化 合理化 浮いた時間をコミュニケーション、設計に genkins 自動化を一歩進める → マシンからの通知 おかしい時だけ知らせる 上の3つを三脚椅子に例える。 → 3つ揃わないと確実に倒れる。 テストという言葉の定義 言葉の示すものがバラバラ 会社ごと、組織ごとに意味するところが違う。 粒度とか範囲、フェーズで捉えると限界がある。 テストの再分類 誰が何のためにテストを行うのか 開発者 開発促進 自信をもって開発するために 顧客(プロダクトオーナー) 進捗管理 受け入れテスト 品質担当 品質保証 パフォーマンスやセキュリティ等
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
