ドキュメントを書けば？
これ。当然私は「いいこと言ってるなぁ」派。
これに寄せられるいくつかのコメントについて。
新規サービスをテスト書かずに立ち上げた奴らが創業者利益でがっぽり勝ち逃げして後から入った真面目な若者が負債による圧迫で「こんな機能追加するのにこんなにかかるの？」みたいに詰められてる姿が目に浮かぶ
それはテストを書くかどうかの話より、技術的負債を積み上げ続けたまま勝ち逃げする人たちの批判ですかね。
テスト書いてあっても技術的負債が積み上がったプロジェクトだってあるし、テストはないけどプロジェクトのメンテナンスちゃんとしてるプロジェクトもあるし。
一般論としてテスト書いてる現場のほうがメンテナンスちゃんとしてる傾向にはあるだろうけど、直接の論点とは違うんじゃないですかね。
インフラとかライブラリ系はテスト書きまくっとくと安心感が凄い。簡単なテスト書いてるだけでも結構自分の思考の漏れが見つかる事多いしね。フロントはあんま関わらないからノーコメント。
そうそう、ライブラリは書いたほうがいいし書くべきなんですよ。読みづらいコードも増えるし。
でも、フロントはそんなにいらない。
テストを書くか書かないかは自由かもしれんけど動く事を保証するための動作確認をテストと言っているなら他人に説明するためのシナリオは必須だと思う
シナリオとは？ TDDのシナリオですかね。私はシナリオとかスペックという概念(仕様とテスト実装、両方を表すようで両方ともと違う)は無駄な中間概念だと考えているので嫌いです。
普通にドキュメント書いて、あとminitest書けばと思う。
「よくできたRSpecはテスト自体が英語で仕様を表す」みたいなのって水素水とか、声がけで水の結晶が〜みたいなレベルのカルト思想だと思う。
共感してる人は元記事の矛盾に気づいてるのだろうか?"ユーザーに価値を届ける"事には"ユーザーの価値を壊さない"事も含まれる筈なのだが;多分これが許されるのって最初から完璧なコードが書けて修正不要な場合だけ
テストを書けば確かに価値を壊すリスクは減るとは思う。これはビジネス側の解釈なのでケースによるけど、壊すだけの価値がある時点でテスト書けばよい。たいていのスタートアップは誰も使わないとかのレベルで停滞してるわけで。
自称出来る人のドキュメントなしテストコードなしのソースを引き継いだ経験のある人はまったく賛同できないだろうな。それやるならお前が一人で開発して一人で墓まで持ってけよって。
そう、これなんだけど、「テストが書かれていてドキュメントがない」状況とその逆だったら、ドキュメントがあってテストがないほうが全然よくない？ つまり、テスト書かなくてもドキュメントがちゃんと用意されてればこの問題はある程度緩和されると思う。実際、ここの仕様の意味がわからないというときにテスト読むって少し無理な注文だと思う。(少なくても教科書的に、「あぁこのメソッドはこういう振る舞いが期待されてるのか」と納得した経験はかなり少ない)
いいエンジニアはコメントを書かない、というかコメントにはBad Codeの臭いがあるのは確かにそうなのだけど、コメントを書かないにしてもドキュメントは書いたほうが良い。
例えば本番データを開発環境に投入するコマンドとか、キャッシュクリア、デプロイ手順(capistranoで自動化されてるにせよ普通にrollbackしようとしたら変なエラーが起きたりとかけっこうある)、ビジネスロジック上わかりづらいが重要な違いがあるメソッド(`Article.published`と`Article.visible`とか)。
ちなみに、昔自分がやったプロジェクトでRSpecでゴリゴリテスト書きまくってカバレッジも優秀なRailsアプリがあったのだけど、紆余曲折あって運営元が変わって、２年後くらいに見に行ったら一切実行されてないテストと「ドキュメントが一切ないクソプロジェクトなんですよ」という現場の声にショックを受けたので、今やドキュメント85, テスト15くらいの割合で考えてる。
