ToDoリストのすすめ - 日々常々
TDDBCでTAやってぼやっと思ったことシリーズ。シリーズ？続くの？ - TDDBCのお題はざっくり「何ができるか」が書かれてることが多いですが、これはテストを書くのに十分な粒度ではありません。少なくともお題をそのままテストメソッド名にしてしまうのはダメなパターンです。簡単なところは上手く行くこともありますが、すぐに厳しくなると思います。 これは実際の開発でもよくあります。例え設計者が別に居たとしても、詳細設計書に書かれているものが十分であったことはあまり記憶にありません。咀嚼して適切な粒度に整理し直す必要があります。*1 TDDでのテストの歩幅は人それぞれだなので、明確な答えを示すことはできませんが、「何をテストすればこれができたと言えるか」が明確でない……言うなれば assert から書き始められない場合は、階段の段差の高さが自分のスキルに見合っていないと言うことです。 まず全体を見て
GitHub PagesでSphinxを使ってみる - 日々常々
http://pages.github.com/ GitHub Pages というものがある。簡単な規則に沿ってページを作ればサブドメインでのページが作れる感じのサービスと認識した。規則は簡単。 irof.github.com というリポジトリを作る そこに index.html を置く そしたら後はGitHubが勝手に良いようにしてくれて、http://irof.github.com/ でアクセスできるようになる。素晴らしい。（この時点では「hello, world」とだけ書いてた） でもHTMLなんていちいち書いてられないし、GitHub Pagesで紹介されているようなJekyllなんてのは知らない…と言うかHTMLはSphinxで出したい。 しかし素直に sphinx-quickstart で出力したHTMLをpushしたところで、GitHub Pagesは _ で始まるのを対象と
テストが間違ってたら？ - 日々常々
「テストが間違ってたらどうするんだ」 自動テストの話をするとよく言われます。テストが間違ってたらわからないじゃないか。手動テストであれば、注意深く目で確認していれば間違いに気づけると言う主張です。 「目で確認していれば気づける」のは間違いではありません。必ず気付けるわけではありませんが、十分な知識を持った人が、十分な集中力と責任感をもってエビデンスを確認すれば、誤りに気付ける可能性は高いと思います。 品質(主に機能性)を目的とした自動テストでも、それを行う必要があります。それがテストコードのレビューです。 手動テストの場合、テスト実施前に手順や確認項目のレビュー、実施中の確認、実施後のエビデンス確認と、人が確認するタイミング*1が三カ所あります。 これに対し自動テストの場合、テストが書かれた時のみ。実行中は勿論、実行結果の確認に注意はありません。ただ成功か失敗かだけなので。ならば、テストコ
テストと言うパートナー #TddAdventJp - 日々常々
TDD Advent Calendar jp: 2011の 12日目です。 前：あなたは写経しますか - pocketberserkerの爆走 次：TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP - うさぎ組 テストはパートナー 「何を言ってるんだ？」な感じかもしれませんが、私にとってテストはパートナーです。 私がTDDのコンテキストで言う「テスト」はDeveloperTestです。このテストは開発者の開発者による開発者のためのテストであり、つまり開発者たる私のためのものです。私だけのためにテストは働いてくれます。 テストに対する不安 TDDや自動テストと言う言葉に触れ、「いざテストを書こう」と思った時。もしくはよく知らないままテストコードを書かなければならなくなった時。テストに対して不安を感じると思います。TDDは「不安をテストにする」とか言いますが、そもそもテス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
