外部に依存したコードもテストで駆動する / Test-Driven Architecture - AWS Dev Day Tokyo 2018

外部に依存したコードもテストで駆動する / Test-Driven Architecture - AWS Dev Day Tokyo 2018

alexaスキルを開発する過程でみるテストの書き方

流れ

現状確認

テスタビリティをこじあける

安全な変更と今後の継続開発のために

脳天気な正常系でよし

網羅性は最初はいらん

選択肢

easy, simple

simpleがよいっぽい

テストの流れ

まずはとにかく正常系を書く

equalの判定をもうちょっと細かくする

その過程で、ランダム性が入ってるせいでテストできないことに気づく

レガシーコードのジレンマ

接合部(seam)

今回の例だと、コールバックでまとめて、次のidを取得する部分を注入できるようにしてる

ここまででも、まだ汚くて、最小限のこれから戦うためのテストができたというだけ

https://gyazo.com/54aaf3eaa708f3064c0412751f2c7466

次の仕様変更を、テストに落とし込んで、まず失敗さす(RED)

ここで、タスクをひたすらred green 繰り返してる

しかしこのままだときれいにならない

リファクタリングだ

たとえば今の状態だと、使用の変更と基盤の変更が同時にくるとつらい

ビジネスロジックを基盤に依存させないようにしたい

モデルを分離する

これまでのテストをgreenに保ちながら内部をきれいにする

sessionクラスを導入

これのテストをまず書いて、コードを書く

既存のコードをこれに置き換える

これを繰り返して、既存のコードからsessionというクラスを用いてビジネスロジックを剥がしていく

さらに、まだlambdaに残ってるものを剥がすために似たようなことを繰り返す

dump機能をsessionに入れる

接地面を最小に

クラスも隠蔽して、startとrestoreだけに

アーキテクチャを定める

変化しやすいものに依存しない

情報とデータの違い

データは事実

情報はデータから作られた意味のある正しいもの

事実を追記していくようなデータにする

登場した書籍

レガシーコード改善ガイド

clean architecture

安定依存の法則

SQLアンチパターン

情報とデータ

テスト駆動開発

以上の流れは、テストがないコードにどう切り込んでいくかを説明するもの

現状確認

最初にこじあける

スイートスポット

脳天気な正常系

モデルの分離

具体的に言うと、ビジネスロジックを書くためのコードを作って、置き換えてく

アーキテクチャを定める

外界依存を減らし、接合面を減らす

事実を格納して、情報を取り出す

コレ自体はもちろんためになるし大事だが、アーキテクチャという観点からこの方針を得るのはちょっと天下り的なように思う

テスタビリティのこじ開けとかRed Greenとかは誰でもできるというか、ひらめきがいらない

しかし、モデルの分離とかはセンスや経験が必要な気がする

Sessionというクラスを思いついたり、事実ベースでデータを貯めるとか

こういう、いい感じになる型やモデルを考えるのは好きだったが、テストはそれをより安全に大胆に進められるようになるということか

突然こういう型を入れよう！としてプルリク出しても、信頼を得にくい

テストで舗装してからぶちこむと良さそう