スキップしてメイン コンテンツに移動

テスト駆動開発講座の自分用メモ

下記サイトにはテスト駆動開発の動画の講座に加えて、動画の書き起こしがまとめてあります。

講座一覧

［動画で解説］和田卓人の“テスト駆動開発”講座：連載｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd

以下は僕が動画を見ながらメモしたものです。

視聴した講座

第6回　「写経」でTDDの手順や書き方を学ぶ：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0006

  • 学習方法
    • 写経
    • セミナー／ペアプロ

第7回 「経験者」からTDDのリズムを学ぶ ――セミナー，ペアプログラミング，レビュー，動画：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0007

  • 写経では得られない典型的なものの一つが「リズム」

第8回 テスト駆動開発の「サイクル」――まず受け入れテストで土台を作る：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0008

  • 受け入れテスト／機能テスト。まず、外側の視点から受け入れテストを書く
  • 例）ブラウザが，サーバに対してあるURLでGETアクセスをかけると，そのURLに対応したXMLを返すよ，というプログラム
    • サーバ側のプログラムがまったく存在しない状態
  • Selenium自体は，TDD的な無から有を生むようなアプローチというよりは，回帰テストとして使っていくのが良いのではないか

第9回 テスト駆動開発の「サイクル」――次にテストリストでToDoを洗い出し，レッド，グリーンでサイクルを回す：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0009

  • 大きいテストを書く
    • そのテストを満たすために、実装するToDoを書いていく
    • 実装の段階を細かくしていく
    • 大きいテストはレッドのままだが、その中の細かい機能をレッド・グリーンのサイクルを回していく。その細かいのが全てグリーンになったら、大きいテストもグリーンになるというサイクル

第10回 テストの最小単位は不安：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0010

  • 上記の細かい機能のテストの最小単位は、不安という感情。
    • このコードは自信がある、または、以前書いたことがあるコードだと思うなら書かない
  • 学習テスト
    • 暗記できていないメソッドの使い方、よくわかっていない使い方についてテストしながら理解する
    • 例えば、正規表現によるパターンマッチ。いきなり機能の実装を書き始めるのではなくて、パターンマッチのライブラリの使い方を理解しながらテストを書く事も
    • テストコードの中で試しに実装していたものを、リファクタリングで育ててつつ、プロダクトコードへというようなやり方も

第11回　テストの資産価値：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0011

  • 最初に大きなテストを書いて失敗させる
    • 例）アプリ起動後に初期化処理が実行される。その結果をテストするコードを書く
  • これを成功させるために、小さいテストを書いて開発を進める
    • 例）初期化処理を構成する細かいメソッドのテストを書く
  • 開発を進めた結果、最初の大きなテストが成功する
  • その後仕様変更等が行われた場合、小さいテストの結果が真っ赤になり、メンテナンスが他変になる場合がある
  • 小さいテスト群と大きいテストは資産価値が同じと考えて良いのではないか。メンテナンスが大変なら小さいテスト群は削除してしまってよいのでは
  • 不安が残る部分は残しておいた方がいいと思う

第12回　モックオブジェクト技法：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0012

  • モック：仕様のシミュレート
  • 開発中のクラスＡがあり、別チームが開発しているまたは、まだ開発されていないクラスＢ，Ｃがある場合は、クラスＢ，Ｃの偽物（モックオブジェクト）を作ってシミュレートしてクラスＡをテストする
  • その後、本物のクラスＢ，Ｃが出来上がったら、Ａ，Ｂ，Ｃを結合してテストし成功させる
  • ある日、クラスＣに仕様変更が発生する。この場合のテストの修正は？
    • Ａ，Ｂ，Ｃを結合した時のテストは当然仕様変更に伴い修正し、テストを成功させる
    • モックオブジェクトのメンテナンスは、本物を結合してテストが通っているのなら、メンテナンスの大変さがありテストとしてそんなに資産価値がないので捨ててしまって良いのでは？

第13回　私のTDDへの目覚め：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0013

  • TDDに対して「これは！」と思ったタイミングは？
    • 今まで単純なバグが多かった
    • ケントベックの本を写経してみた
    • プログラミング能力の底上げに使えるんじゃないかという体験

第14回　テスト厨，TDDの壁，DBやGUIのテスト：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0014

  • TDDの壁：テスト駆動でできることとできないことの存在
    • DBや画面を伴うテストは割に合わない
  • テスト厨：なんでもテストでかけるという熱中状態
    • テストの資産価値として割に合わないものもテストを書いてしまう
  • 壁を越えると
    • 割に合わなかったものをツールにまかせて、資産価値のあるものをテストを書けるようになる
    • 画面は目でテストして、画面とは離した部分でテスト書けないかと考えられるようになる

第15回　追い込まれたときのテスト：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0015

  • 「追い込まれている」というのが理由で，テストをさぼることはありますか？
    • 小さいテストを少なめにしてコードを書いたこともあった
    • 逆に追い込まれたときに、動作確認の足場として集中してテストの足場を作ったという例も

第16回　プログラミング言語とTDDは，どちらを先にマスターすべきか？：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0016

  • 言語をマスターするためにTDDを使うような使い方も→学習テスト

第17回　リファクタリングをどこまでするか，いつやめるか：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0017

  • リファクタリングはどこまで？
    • 重複がなくなるまで。DRY（Don't repeat yourself）
    • モヤモヤがなくなったら

第18回　公布済みインタフェースのリファクタリング：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0018

  • Publish(ed)インタフェース：Web APIのような。なかなか好きに触れないインタフェース
    • リファクタリングではいきなり廃止しないで、非推奨にして残しつつ新しいインタフェースを追加する。移行期間を設けてしかるべき時期がきたら廃止するような運用

第19回　チーム開発での規約・規律：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0019

  • 他の人のテストが読めないってことが起ってくるので、規約（テストの書き方の均一性を保つためのもの）を決めるのは重要になってくることも

第20回　テストコードの重複はアリかナシか：［動画で解説］和田卓人の“テスト駆動開発”講座｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0020

  • プロダクトコードは重複がないのが理想
  • テストコードは２つの指針
    • ある程度重複があってもいいから何をやってのかわかるようにとする指針
    • プロダクトコードのように重複がないのが理想とする指針
  • 達人プログラマー（Andrew Hunt／David Thomas（著））「テストコードに重複はあってはならない」
  • 和田さん「重複はアリ」
  • テストのリファクタリングの話は次回（？）以降
2015/08/08 一部修正
ラベル:

コメント

コメントを投稿

このブログの人気の投稿

Javaでprivateなfieldやmethodにアクセスする

JUnitでテストしてると、privateなフィールドにアクセスして、値を参照したりセットしたりしたくなるわけですが、よく使うのでメモしておきます。 例えば、次のような対象のクラスがあるとします。 public class ParentClass { private String hoge = "ParentClass!!"; public void dispMsg() { System.out.println("dispMsg:" + hoge); } private void privateDispMsg(String msg) { System.out.println("dispMsg:" + msg); } }
コメントを投稿
続きを読む

GolangでWindows GUIアプリケーション

GUIアプリ作成の前提 社内ツールとしてexeで配布 開発環境はGoLandを使う 社内ツールとしてexeを配布ということであれば、Visual StudioでC#による開発だと思います。しかしながら、Go言語を習得したいのと、GoLandの補完機能が便利で、Android Studio使っていたこともあり、とっつきやすいという点からGo縛りでGUIアプリケーションを考えたいと思います。 lxn/walk Windows application library kit for Go. Windows向けしか考えていないので、まずこのライブラリなのですが、ボタンやコンボボックスが思ったように並ばなかったり、手軽にイメージボタンを配置したりなど、簡単にレイアウトを変更できない課題に直面しました。レイアウト作成だけで時間を取られてしまいます。そう言えば、Androidアプリ開発のときは、XMLでデザイン部分を切り離してたのを思い出して、今回の調査の運びとなりました。 fyne-io/fyne Cross platform native GUIs designed for Go based on Material Design. Supports: Linux, macOS, Windows, BSD, iOS and Android. walkと比べると、クロスプラットフォームで作成できるのですが、こちらもコードの中にデザインを書いていく形でした。 therecipe/qt therecipe/qt allows you to write Qt applications entirely in Go or JavaScript. Qt Creatorなるものがあるようで、デザイン部分を切り離せる印象はあるものの、最新のPCでもビルドに時間がかかるようで、学習コストもかかるという記事を見かけて断念しました。 どうしたものかとツイートしましたら、下記のようにご助言をいただいた。 同じ課題に対し色々試した結果、PWAのフルキャッシュドに落ち着いた。中身はGo+WASMで。 https://t.co/e60whDTV16 — のぼのぼ📡 (@nobonobo) July 21, 2020 PWA 早速調べてみました。Googleが進めているプロジェクトで、ネイティブアプリのよ
コメントを投稿
続きを読む

Eclipseの高速化メモ

Eclipseが重いと一言に言っても、いろいろな工程での話があると思いますが、過去記事のなども含めてこの記事にピックアップしておきたいと思います。以下はWindows環境での話です。
コメントを投稿
続きを読む