今日は、チーム9人全員で「プライベートメソッドのユニットテストは書くべきなのか？ ディスカッションができた」記念日 - エンジニア的なネタを毎週書くブログ
今日はとても素敵な一日になりました。 私を含めたチームメンバー9人が、一つの技術的な話題に対して30分話し合う会を開けた日。 何より嬉しかったのは、この会そのものが、メンバー間でのやり取りからほぼ自然に出てきたことなんです。 回想：本当に「スモール」だった時期 私の今のチームは総勢9名のチームなのですが、大まかに分けても4種類くらいののサービス（検索から予約、管理画面も。）を担当している、プロダクト的にはかなりマッチョなチームです。 これらのサービスはどれも「似ている」のですが、歴史的にバラバラに作られてきたため、アーキテクチャやフレームワーク、コードの思想は全部バラバラです。 以前は、このバラバラなプロダクトを、チーム内でもバラバラに担当がついていて、2～3人の少人数チームが3つ、という状態でした。 「似ている」ものをバラバラに作っているので、同じようなものをお互い作っていたり、同じよう
JUnit実践入門 読書レポート Part1 & 第7章 - エンジニア的なネタを毎週書くブログ
ほぼ発売と同時に買ったにもかかわらず、ずっと積読本になっていた「JUnit実践入門」をようやく読んでいます。 ここ最近で、バグによるリリーストラブルがあったり、単体レベルのバグがQAでボロボロ出てきたりということがあったため、改めてテストコードの品質（テストとしての品質はもちろん、可読性やメンテナンス性も含めて）について考えていたのですが… もやもやしてたこと、ほとんど書いてあるじゃん！ ぐぅ、もっと早く読んでいればよかった。 レポートの前に、現状の問題 自分の書いたものも含めてなのですが、いまの身の回りにあるテストコードの多くにおいて、可読性が低く、何をしているテストコードなのかわかりにくい という問題が見られます。 （そうでないものも多くあります） 自分なりに原因分析をすると、以下のような原因が見られます。 テストメソッド名に意味がなく、コメントも無いので、何をするテストなのかよくわか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
