FizzBuzz 問題をテスト駆動型開発で実装する (実践編) - Qiita
2017.07.02 編集しました。 先日投稿した準備編に引き続き、今回は実践編として FizzBuzz 問題の TDD を進めていきます。 準備編のおさらいと実践編の流れ TDD のメリット 動く綺麗なコードを実現出来るため (Clean code that works)。 実装を終えてから、テストで出たバグの影響範囲全てを修正していくという手戻りを少なくできるため。 保守性の高い設計を実現出来るため (テストしやすい == 変更に強く保守性が高い、テストしにくい == 設計改善の余地あり) FizzBuzz 問題の要件 要件 内容
FizzBuzz 問題をテスト駆動型開発で実装する (準備編) - Qiita
先日、Microsoft の開発者向けイベント de:code2017 に初参加しました。 最新の技術動向から、レガシー系開発現場をどうマネジメントし変えていくか、と幅広いテーマの話を聞くことが出来、とても面白かったです。 中でも DO03 50 分でわかるテスト駆動開発 というセッションのライブコーディングの題材であった、FizzBuzz 問題のテスト駆動開発 がとても印象的でした。 そこで、そもそもテスト (単体テスト) とは？ から振返りつつ、自分なりに実践してみました。 実践内容を順追っていくと長くなりそうなので、準備編と実践編の 2 つに分けて投稿します。今回は、準備編です。 単体テストとは 一言で言うと 単体テストとは、クラスやメソッド等の小さな単位でプログラムが仕様書通りに動作するかを確認するテストです。 単体テストの手法 主に、以下の 3 つに分けられます。 機能確認テスト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
