TDDという名の幻想... - Qiita
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を採用すると開発時間が膨らむ、すなわち、開発コストが 膨らむからです。そして、ソフト開発では細かな仕様は変化していきます、 するとTDDではそれに合わせ、テストを修正していかなくてはなりません。 また、TDDで書かれたテストが全てのケースを抜けなく網羅できていること は稀です、抜けは必ず
【初心者向け】テストコードの方針を考える（何をテストすべきか？どんなテストを書くべきか？） - Qiita
はじめに 「テストコードを書きましょう」とはよく言われるし、テストコードが大事だってことも理解できるんだけど、何をテストしたらいいの？どんなテストを書いたらいいの？と迷っている初心者プログラマさんは意外と多いのではないでしょうか？ そんな方たちに向けて、この記事では僕が普段意識しているテストコードの方針を紹介します。 おことわり 本来であれば具体的なコード例も豊富に入れたいところなのですが、かなり時間がかかってしまうので、いったん文章メインで記事を公開します。 もしかすると、そのうちコード例も一緒に盛り込んだ「リッチバージョン」を公開するかもしれません。 この記事の前提条件 この記事ではあくまで、「今現在、筆者が仕事で書いているテストコードの方針」です。 そのため、状況が異なると適用しづらい方針も出てくるかもしれません。 筆者は以下のような現場でコードを書いています。 月額定額で、お客様と
テストコードとか書いてみてもいいんじゃない？ - Qiita
from dog_bark import dog_bark def test_dog_bark(): assert u'ワンワン！' == dog_bark('Japan') assert u'Bow wow！' == dog_bark('USA') となります。 実際にdog_bark関数を実行して、想定した結果文字列と直接比較するというコードです。 世に言うテストコード書こうぜ！という主張はこんな感じのコードを量産しようぜ！ ということになります。特に難しいことはないですね。 テスト実行は例えばPythonのPytestなら $ py.test test_dog_bark.py でOKです。もしテスト関数を増やしたとしても勝手にファイル内のテストを認識して 実行してくれます。 ちなみにどの言語のどのテストフレームワークもこのくらいの機能はあります。 (コンパイルがいる言語は多少手間が増
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
