BDDについて自分なりにまとめてみた - ukstudio
BDDという言葉も割と人によって指すものが違うようなので「俺の中でのBDDはこうだよ」って内容のエントリ。別に絶対的なものでもないと思うので参考までに 結論から とりあえず結論だけ知りたい人向けに。 BDDにはふたつの種類がある TDDの言い換えのBDD(開発寄り) ATDD(受け入れテスト)でのBDD(ユーザ寄り) 振る舞い BDDは振る舞い駆動開発と言われたりするように、テストという言葉のかわりに振る舞いという言葉を使う。日本語的には仕様と言うほうがわかりやすいかもしれない。多分、BDDのイメージが掴みにくいのはこの振る舞いという言葉にあると思う。と言うのも振る舞いと言うのは、人の立場よって変わるからだ。例えば、プログラマがあるクラスを実装している時に言う振る舞いはそのクラスのメソッドとかの仕様になる。逆にユーザレベルの人が言う振る舞いはアプリケーションの要件・動作を言うだろう。 つま
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
最適化の第二法則（要約版） - OGINO Masanori@はてな
これはThe Second Law of Optimization (Abridged) – the Voidの日本語訳です。原文と同じく、Creative Commons 表示 - 非営利 - 継承 3.0ライセンスの下で自由に利用できます。 僕は同じ題名の元の記事（英文）がみんなが読みたいと思うよりも長いと気付いたので、要約したものを用意した。 今や誰もがこの「最適化のマントラ」を聞いたことがあるだろう。「やめとけ」 これは一般的に三つのルールに内包されている。最初の二つはこのマントラの複製で、三つ目のルールは「まだ」という抜け目のない言葉を唯一無二のルールに付け加えて「エキスパート」に宛てている。 時期尚早な最適化――僕らの大部分は身に覚えがある。この言葉がとても有名な理由だ。言うなれば格言だ。アルゴリズムを肉付けせず、結果をよく確かめもしない内に、ただ出力に驚嘆してスマートなトリッ
privateメソッドのテストについて
瀬良 @shela_ @irof publicからprivateを含めて検証するのと、private単体だけで検証するのであれば、先にprivate単体で検証しておいた方が安心感があると思う 2012-08-25 16:38:24
技術的負債を管理する
1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す
テストコードがないコードだけが技術的負債じゃないよ - methaneのブログ
私は「レガシーコード改善ガイド」を読んだことがないのですが、世間的に「テストコードがないコードが技術的負債」という認識が広まっているようです。 レガシーコード改善ガイドを批判するつもりは全くありませんが、たんにその本の中で使われている「レガシーコード」の定義に一致する物だけが技術的負債だという考えには反対します。 技術的負債とは、将来必要とされるメンテナンスコストの期待値だと思います。全てのコードは、メンテナンスを放棄するまでは技術的負債です。一方、メンテナンスコストを差し引いた上でそのコードが将来生み出す利益の期待値が、そのコードの資産価値だと思います。テストコードがないコードでも、利益を出すなら正の資産になります。 もちろん、資産価値をより大きくするために、技術的負債を減らすことは良いことです。技術的負債を下げる＝メンテナンスコストを下げることで、テストはその有力な手段の一つです。他に
LiveCodingに学ぶプログラミングの三原則 : 404 Blog Not Found
2007年09月16日04:30 カテゴリArt LiveCodingに学ぶプログラミングの三原則 Mozilla24のLiveCodingの解説をやってきました。参加された方、お疲れさまでした。ほんと楽しかった。 言語もC++ありJavaありJavaScriptありActionScriptありPerlありとまちまちで、Editorもemacsありvimあり秀丸ありとまちまちでしたが、それでも全LiveCoderの共通項がはっきり見えたので、それを書き留めておきます。これらの共通項には私も含まれます。 コピペを恐れるな(don't be afraid to be a copycat) 参加者の一人として、100%フルスクラッチで書いていた人はいませんでした。たいていは関数単位でコピーし、それを適宜書き換えるというやり方をしていました。学校のテストでは反則もいいところですが、大人の世界ではこ
状態のあるコードに対するテストの自動生成 - 西尾泰和のはてなダイアリー
BLUE*アルゴリズムを実装してみたので、せっかくだからテストの自動生成をやってみた。 今回テスト対象にするコードの仕様は 開く、閉じる、書き込む、の3つの操作ができる 開いてないのに書き込んだり閉じたりしたらエラーになる というもの そしてこちらがそれの「バグのある実装」： class Target(object): # bad impl. def __init__(self): self.opened = False self.closed = False def open(self): self.opened = True def write(self): if not self.opened: raise RuntimeError if self.closed: raise RuntimeError def close(self): if not self.opened: rais
変数名の力 - いいプログラムを書こう
はじめに名前ありき。 これは洋の東西を問わず、呪術魔術の基本として伝えられる語句です。 いきなり魔術や呪術や出してしまって引いてらっしゃる方も多いとは思いますが、コンピュータの世界ではプログラマは一種の魔法使いかもしれません。 プログラミング言語やスクリプトといった呪文、ミドルウェアやデータベースエンジンといった触媒を使いこなし、さまざまな現象を仮想空間に作り出します。 そして実際に、非常に優れた専門家は、敬意を込めて、同じ開発者から(特に英語圏では)こんな風に呼ばれます。 ─ウィザード。 多くの系統の魔術や呪術では、「名前」というものは、すべての基本です。 「まじない」とはそうあるべく縛ること、そして最も強力で基本的な縛りが名前なのだそうです。 名前がないものは存在しないと同じ、名前は、それがそこにあることの証明でもあるのです。落ちているゴミも、ゴミという
gitの入門用のチュートリアル"Learn Git Branching"を訳した | 48JIGEN *Reloaded*
gitの入門用のチュートリアル"Learn Git Branching"を訳した 2013/03/18 ここで公開してます。スマホからだと動かないのでPCで見てください。 http://remore.github.com/learnGitBranching-ja ChromeとFirefoxでは動作確認してます。翻訳リソースはgithubに置いてあります。 Laern Git Branchingは： グラフィカルにgitツリーを操作しながらrebaseとかmergeとかを学べる IDEA * IDEAさんとかHackerNewsとかで、1か月くらい前に話題になってた MIT Lisenceで公開されてて自分で演習問題も作れる というツール。公開されてから1か月くらいしか経ってないのに、既に中国語、韓国語、フランス語の3か国語に翻訳されてる。海外の人仕事はえーと感心しました。 春だし新人さん
ペアプログラミングは大衆向けでない？
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
ソースコードの質：気難しいプログラマ：エンジニアライフ
近年、ハードウェアの性能向上などにより、IT業界をめぐるインフラは、ようやく市場の要求に耐えうるようになってきた。以前はプラットフォームの陳腐化によって5年と持たなかったソフトウェアの平均寿命は、ここへきて徐々に延びつつある。 このような状況の中でソフトウェアに求められるものは、繰り返し行われる機能追加に耐えうる「拡張性」と、長期に渡って品質を保てる「保守性」だ。これらの課題については、クラウドのような分散コンピューティング技術や、オブジェクト指向デザインのような設計思想といった大きな枠組みの中で数多く議論され、ソフトウェア技術の進歩を押し上げてきた。「実際の現場においてこれらの課題をインプリメントするのは、システム設計者やSEといった上流工程を任された人間の役目である」と一般に言われている。 彼らのアウトプットは、基本的に文書（Document）だ。文書は日本語や図から構成されており、読
VSSヤバイ - じゃがめブログ
ヤバイ。VisualSourceSafeヤバイ。まじでヤバイよ、マジヤバイ。 VSSヤバイ。 まず高い。もう高いなんてもんじゃない。超高い。 高いとかっても「WindowsOSくらい？」とか、もう、そういうレベルじゃない。 何しろ７万円。スゲェ！ なんかフリー版とか無いの。オープンソースのバージョン管理アプリを超越してる。低機能だし超高い。 しかもファイル破損するらしい。ヤバイよ、破損だよ。 だって普通はCVSとかファイル破損しないじゃん。だってバージョン管理アプリなのに変更履歴が消えちゃったら困るじゃん。履歴比較できないとか困るっしょ。 前のバージョンに戻そうとロールバックしたらファイルが壊れるとか泣くっしょ。 だからCVSはファイル破損しない。話のわかるヤツだ。 けどVSSはヤバイ。そんなの気にしない。破損しまくり。Analyzeコマンドを叩いても全く復旧できないくらい取り返しつかない
作業中断のコスト
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
DRY原則の利用: コードの重複と密結合の間
原文(投稿日：2012/05/25)へのリンク DRYは重複とそれに伴うメンテナンスの問題を軽減するものだが、誤用すると密結合を生み、可読性を損うおそれがある。教訓：ソフトウェア開発原則は、ほかの原則やパターン、プラクティスを考慮して適用しなくてはならない。 DRYは Don’t Repeat Yourself の略語であり、Andy Hunt氏とDave Thomas氏が書籍「The Pragmatic Programmer: From Journeyman to Master」（邦訳：「達人プログラマー―システム開発の職人から名匠への道」）で最初に言及したソフトウェア開発原則だ。その原則はこう述べている。 知識のあらゆる部分はそのシステムにおいて単一で、曖昧さのない、信頼できる表現でなくてはならない。 ここでHunt氏は重複による負の影響と、それゆえにDRYを利用することの重要性を強調
派遣PG時代の思い出
@vjroba 某N社で「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われたことがある。僕は300行で挫折したが、1万行メソッドを書ききった強者がいた。クラスを作るには申請書が必要だった。 2010-05-11 12:42:06
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラマが欲しい仕様書とは
TDDで「テストばかり書いて間に合うのか？」と質問されたときの正解 - きしだのHatena
オブジェクト倶楽部 - TOPページ
ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜 #devsumiA
