BDDについて自分なりにまとめてみた - UKSTUDIO
BDDについて自分なりにまとめてみた Published on 2011-07-02 Updated on 2011-07-02 BDDという言葉も割と人によって指すものが違うようなので「俺の中でのBDDはこうだよ」って内容のエントリ。別に絶対的なものでもないと思うので参考までに 結論から とりあえず結論だけ知りたい人向けに。 BDDにはふたつの種類がある TDDの言い換えのBDD(開発寄り) ATDD(受け入れテスト)でのBDD(ユーザ寄り) 振る舞い BDDは振る舞い駆動開発と言われたりするように、テストという言葉のかわりに振る舞いという言葉を使う。日本語的には仕様と言うほうがわかりやすいかもしれない。多分、BDDのイメージが掴みにくいのはこの振る舞いという言葉にあると思う。と言うのも振る舞いと言うのは、人の立場よって変わるからだ。例えば、プログラマがあるクラスを実装している時に言う振
TDDをはじめる条件 #tddbc #tddconf - やさしいデスマーチ
色々と忙しすぎてブログが書けません。 JavaOneの話とか、JUnitの話とか色々書きたいんですが…もうしばらく我慢なのです。 で、TDDの前方依存と後方依存で意見が欲しいとのことなので自分なりの意見を。 技術的な前方依存 『TDDを始める前と終TDDを実際やるために必要な技術』 ・最低限対象言語でコードがかけるようになって ・最低限テスティングフレームワークを使えるようになって ・リファクタリングをしっかり学んで ・対象言語でのきれいなコード、設計とは何かを知って ・テストファーストを知って こうしておそらくスタートライン。 自分はこれは疑問です。 最後の「テストファーストを知って」という部分はTDDに関することですけど、それ以外ってTDDを始めるスタートラインではなく、ソフトウェア開発としてのスタートラインかと思います。 言い換えると 最低限対象言語でコードを書けないと、ソフトウェア
自覚 - naoyaの寿司ブログ
きれいなコードを書こうぜ、といってるのに対して製品の善し悪しに綺麗なコードがいいかどうかなんて関係ない、みたいな話とか 仕様書とかぜんぜん読まないから仕様書なんて全く必要ない、さっさとコード書けとかコードだけで語れ、とか TDD されてないからリファクタリングできないんだ、だからカバレッジ100%にするんだ、ぜんぶテスト書け、とか エンジニアは技術から出発して需要を考えない、だから問題から入れ、技術なんて関係ない、とか 企画屋は技術のことがわかってないから、夢物語りばっかり語るんだ、エンジニアがサービス作るべき、とか そういう、何かを反面教師に反対の考え方を支持するみたいなのは注目浴びやすいけど、視座をもうすこし中立にして考えると、だいたいおかしい。かくいうぼくもそんな風に煽ってる時期がありました、若さって怖いです ─ 中庸って知ってるか。伝統や、むかしから習慣として良しとされてきているこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
