Groovy入門して躓きメモ
Java→Groovy初日で出会ったエラーたちやメモたち。 syntaxもよくわからない中で出会って、解決するのに慣れなかったのでメモしておく。
メソッドの呼び出し間違い
メソッドの呼び出しが間違った時
Caught: groovy.lang.MissingMethodException: No signature of method: hogepackage.hogefile.hogemethod() is applicable for argument types: (java.math.BigDecimal, java.util.ArrayList, groovy.sql.Sql) values: ...
特にクロージャの中でエラーが起きるとクロージャのどこでそれが起きているのかよくわからなくて慣れるまで時間がかかった。
変数の宣言のスコープ
http://d.hatena.ne.jp/Kazuhira/20120318/1332083318
before
def sql = Sql.newInstance()
Map.each{k,v->
searchUuidByUser(k,v,sql)
}
eachの中からsqlは呼び出せない。
Caught: groovy.lang.MissingPropertyException: No such property: sql for class: hogepackage.hogefile groovy.lang.MissingPropertyException: No such property: sql for class: hogepackage.hogefile
after
sql = Sql.newInstance()
Map.each{k,v->
searchUuidByUser(k,v,sql)
}
def をつけているとクロージャ内やメソッド内から呼び出せない。
列名が無効
before
def SELECT_USER_POINT_HISTORY = "SELECT ID,POINT,INSERT_AT from POINT_HISTORY where ID = $userId ORDER BY INSERT_AT"
List<Point> pointList = new ArrayList()
sql.eachRow(SELECT_USER_POINT_HISTORY){
Point dto = new Point()
dto.type = it.type
dto.point = it.point
dto.insertAt = it.insert_at
pointList.add(dto)
}
警告: Failed to execute: SELECT ID,POINT,INSERT_AT from POINT_HISTORY where ID = ? AND TYPE != 0 ORDER BY INSERT_AT because: 列名が無効です。 Caught: java.sql.SQLException: 列名が無効です。 java.sql.SQLException: 列名が無効です。
てっきりSQLが悪いのかと思ってタイポかどうか必死に探したけどSQLが悪いわけじゃなかった
after
def SELECT_USER_POINT_HISTORY = "SELECT ID,POINT,TYPE,INSERT_AT from POINT_HISTORY where ID = $userId ORDER BY INSERT_AT"
List<Point> pointList = new ArrayList()
sql.eachRow(SELECT_USER_POINT_HISTORY){
Point dto = new Point()
dto.type = it.type
dto.point = it.point
dto.insertAt = it.insert_at
pointList.add(dto)
}
eachRowの中で参照しているit.typeがselectするものに含まれてないため。 エラー行数をよく見るとit.typeを使っている行を指しているのでわかる
for文の抜けかた
https://stackoverflow.com/questions/3049790/can-you-break-from-a-groovy-each-closure 次のイテレートに入るならeachのままcontinueしてもOK そもそもループを中止したい時(Javaでいうbreakをしたい時)はfindにしてその中でtrueを返してループを終わりにする
pointList.find{
Data data = new Data();
if(nowPoint<it.point){
//breakと同じ。ループを抜ける
return true;
}else{
//continueと同じ。
return false;
}
}
TDDBCに参加＆ペアプロデモをしました #tddbc
tddbcにスタッフとして参加&ペアプロのデモをしました。
ペアプロのデモとは
TDDBCではTDDのやり方を学んだ後、参加者がペアになってペアプロをしながらTDDを実践するプログラムになっています。 このペアプロでどうやって進めていくのか、のデモを行いました。 今回は@yattomさんとFizzBuzzを題材にペアプロしました。
やってみて
ある程度台本があるので安心です。ここでこういう説明が入るとか。 でも後はその場の雰囲気です。実際のペアプロをやってみせてるだけなので疑問とかもガンガン言っちゃっていいので気は幾分楽です。 今回は@yattomさんがリードしてくださり説明などもしてくれたので、なんとかなりました。 自分の開発環境を前のスライドに映しながら行うので自分の開発環境へのツッコミも新鮮でした。
デモプレイヤーさんが Vimmer なのが気になる…… #tddbc
— えび🦐 (@ebc_2in2crc) 2017年9月30日
— てらひで (@terahide27) 2017年9月30日
今回@PoohSunnyさんから煽られてデモをすることになったけど、「人前でライブコーディングするのが一番成長するからやってみな」と言ってくれたと聞いて感謝してます:pray: (FizzBuzzをライブコーディングして成長するかは置いておいて、新しい経験だったので楽しかったです！)
その他
- 午後は参加者に混じってペアプロやってた。1年目、2年目のフレッシュな方とペアを組んでみて自分も気づきがあって何より楽しかった。
- tddbcの参加者の方々は話がうますぎる。どんなコードを書いたかを前で発表する時間があるのですが、皆さんプレゼンがうまくて引き込まれる。
- 他の言語チームのコードを見たり話を聞いたりするのがとても楽しかった。Spock使ってみたくなったり、良い興味の入り口になったと思う。次は覚えたての言語で参加したい。
- 皆テストについての興味や悩みが共通事項としてあるので、質問タイムも懇親会の即興LT大会もすごく盛り上がって楽しかった。こんなアットホームで参加者同士でこんなに仲良くなれるコミュニティはすごい。
GitHubのPRで質問が来た場合はソースコードにコメントで回答する。これいいなぁ #tddbc
— おれたま (@AHA_oretama) 2017年9月30日
- ペアプロしている同士ではすぐ疑問解決されるから良いけど他のチームメンバーに逆に伝わらなくなったりしないの？な質問だったと思う。
- PRのコメント/質問をgithub上で返すのではなく、コードのコメントに反映して設計意図を伝える方法良いと思った。
ご査収ください #tddbc pic.twitter.com/VxpMv57vT5
— ガオピン (@gaopin1534) 2017年9月30日
最高だった。
みなさんお疲れ様でした！！！ #tddbc pic.twitter.com/ftomcuBZsL
— Yotaro TAKAHASHI (@PoohSunny) 2017年9月30日
楽しかった！！！
Tokyo Android Meetupで初英語プレゼンしてきた
Tokyo Android Meetupというイベントで初めて英語でプレゼンしてきました。
#11 Tokyo Android Meetup - July Edition - Tokyo Android Meetup (東京都) | Meetup
Meetup内のイベントは日本開催でも外国の方が参加するイベントが多いらしく、hotchemiさんのブログを見て以前からmeetupのイベントに参加してみたいなと気になっていた。
そんな時にCLEMのイベントに参加したことがきっかけでmeetup参加したことないけど喋ってみることになりました:bow: clem.connpass.com
次回のTokyo Android meetupでtalkをすると良いと思いますね😇 cc: @niko_yuwono
— hotchemi (@hotchemi) 2017年6月29日
準備編
初めての英語プレゼンだったので、アドバイス貰った通りどんなことを話すかスライドとそれに合わせてスクリプトを作成していました。 keynoteのnoteのところにスクリプトを書き出してそれを見ながら練習していました。 英語に関しては、先輩に単純な文法のミスや、言い回しのアドバイスなどをレビューもらいました。
また、内容に関しても直前に社内でLTする場があったので日本語で同じ内容を発表してなんとなく内容について雰囲気をつかんだりしました。
当日行って気づいたこと
英会話のレッスンとネイティブの人が話す速さ、全然違うので聞き取れなかった
- 特に単語と単語がつながりすぎて人によっては全く聞き取れなくて辛かった
- 1ヶ月半英会話続けて単語レベルで英語が聞き取れるようになったと思ったけど速く話されるととたんに駄目だし、はっきり発音されないと何も聞き取れないということがわかった。
DMM英会話で女性の先生のレッスンばかりを受けていたことを後悔した
- DMM英会話初めて1ヶ月半くらい経つのですが、「なんか安心できる」という理由だけで女性の先生ばかり選んでレッスンしていた
- 実際エンジニア界隈は男性が多いのでハードルばかりがあがってしまい当日場が和むまで最高にコミュ障だった
だんだんBGMになっていくのがわかる
- 最初は頑張ってついていってたつもりだけど、途中から完全に頭がついていかなくて全然話が入ってこない
- 自分の今のキャパシティはここなんだなということがわかった。これをどんどん伸ばしていけたらいいなと思った。
感想
- レッスンで話される英語と実際の会話で話されてる英語はちょっと雰囲気が違うのでそれを味わう。本当の会話にどれだけ太刀打ちできるか試しにくる意味ではmeetupのイベントとても良いと思った
- meetup参加すると、「英語ができるようになりたい」じゃなくてこの人たちと話がしたいという思いになってモチベーションアップに良い。
- 参加している外国の方、だいたい日本語も知ってる人が多いので日本人に対して色々な事情理解・配慮してくれているなと感じた
- デベロッパーが使う言い回しなどを覚える貴重な機会。同じ境遇の人が多いから真似できる言い回しなど多いなと感じた。
- 今回はすごくアットホーム。10人くらいの小さなイベントで最初の英語プレゼンをするには良い場所だったと思う。たいしたことない話だったと思うのに、ウンウンうなづいて聞いてくれたのがすごくうれしかった。
- 日本の勉強会とも一緒だが、speakerしたことで日本人だからと関係なく話しかけてくれる人もいて助かった。楽しかった。
- まだ私が来るには早かった、と思ったけど参加してみたらすごく楽しくて参加してよかった。
speaker枠でもらった🎉 pic.twitter.com/WxWSdwDrS3
— よこ ち！ (@chiiia12) 2017年7月25日
Second talk is Introduction to Calabash by @chiiia12 pic.twitter.com/noiuq0ofMY
— Niko Adrianus Yuwono (@niko_yuwono) 2017年7月25日
だいぶ楽しんだ模様。定期的に腕試し&モチベーション維持の意味でも良いと思いました。
Spring Bootのキャッチアップにバージョンアップで理解を深めた話
最近Androidアプリ開発からサーバサイドの開発に移り、移って早々SpringBootのバージョンアップをする案件にアサインしてもらった。SpringBootはじめてです！の段階でプロジェクトのSpringのバージョン担当することもなかなかない話かと思うので、Spring Bootのキャッチアップという点からバージョンアップで対応する時に学んだことをここにまとめる。
前提
- 業務で経験していたのはAndroid開発のみ
- そういえば今まで業務でライブラリのバージョンアップを経験したことはなかった
要約
- プロジェクトのSpringBootバージョンを1.2系から1.5系まであげた
- SpringBoot始めたばかりで通常のエンハンス案件をやっているだけでは知らなかったと思える経験・感覚をつかめたので、学習の導入になった
バージョンアップを経験してよかったこと
SpringBootの導入には「はじめてのSpring Boot」でキャッチアップしていたが、そこでは知れなかったこと&もしこのままエンハンスをやっていたら知るのが遅くなってたであろうと思うことをいくつか。
ライブラリの依存関係について
バージョンアップ作業中に一番対応したのがライブラリの依存バージョンの解決だった。
//TODO:例えば
AライブラリとBライブラリが中でCライブラリに依存してるが、AとBはバージョンによって依存するCのバージョンが違う、みたいなことが起こる。バージョンの違うライブラリに依存していると、順番はわからないがどちらかの依存versionしか参照できず、NoSuchMethodErrorで怒られる。この仕組みについて最初わかってないので困惑した。
mvn dependency:treeやpom.xmlのDependency Hierarchyをみながら各ライブラリの依存ライブラリの整合性を修正していく作業が多かったかと思う。
ライブラリの依存関係を理解する過程で不要なdependencyなどを見つけたり、pom.xmlの整理の仕方も多少は身についたかと思う。
Android開発の時はライブラリのバージョンアップの経験がなくてライブラリ間の依存関係について意識することがなかったので勉強になった。
エラーログに向かう感覚の醸成
SpringBootを初めて触れた時、自分が書いたClassとは全く違うClassからエラーが吐き出されることにとても困惑した。今までは、基本的には自分の書いたコードからExceptionが吐かれることが多かったので、原因もわかりやすかった。 バージョンアップの対応にはたくさんのこうしたエラーに対応しなくてはいけないので、数をこなして慣れることができた。最初に感じていたゲッという気持ちはバージョンアップ経験後ではなくなったので非常によかったと思う。
参考にできるネット上のページの感覚
上にも関連することだが、たくさんエラーが出る中でわからないことを調べる時に参考になるページが集中的にインプットされる。最初はどうぐぐったらヒットするのか模索するのでとても効率が悪かったと思うので。 - Maven Repositoryの各ライブラリのDependency部分 - 公式ブログ - Release Note - Githubのissue - Javadoc - その他QiitaとかStackOverflowなどは普通に。。。 こう書いてみると当たり前なリソースな気がするが、これを経験する前はこれができなかったのである。
Springの各種プロジェクト間の関係性について
恥ずかしながら色々あるSpring系のFrameworkについて全く認識しないまま開発に入ってしまった。例えば以下などがバージョンアップを通して気づき経験した。 - starter系はversionが一緒になるのでそれを踏まえて依存関係を解決しなくてはいけない。 - Bootが依存しているSpring Frameworkのバージョンも変わるので、Spring Frameworkの変更点も確認しなくてはいけない。 - パッケージの変更などで新しくspring-securityをimportしなくてはいけなくなったり。 エンハンスだけしていたらあまり意識してなかったと思うので、いいきっかけにだった。まだ理解してないこともあるのだけど少しだけ。
バージョンアップするにあたり個別に対応したところ
どこで動かなくなったかがわからなくなるのが不安だったので、ひとつずつバージョンをあげて「ここまでは動く」を確認しながら進めた。 意外とボリュームが多かったので別記事にまとめる。うん。まとめる。
まとめ
キャッチアップ材料として「バージョンアップしてみる」選択肢としても考えてみるのも良いかもしれないと思った話。状況と必要性もあるが。 エラーのデバッグを集中的に数こなす意味ではSpring Bootの仕組みに慣れるのでよかった。エラー出ても少しは怖くない！ プロダクトの設計や仕様把握はまた別なので、エンハンス始まって泣きながらキャッチアップしてる。
JJUG CCC 2017 Springで登壇しました~新卒2年目が鍛えられたコードレビュー道場~ #jjug_ccc #ccc_l3
JJUG CCC 2017 Springで登壇してきました。
JJUGについては以下。 www.java-users.jp
発表内容については以下を参照ください。 speakerdeck.com
ここからは忘れないうちに感想文。 外部イベントで2回目の発表でした。（1回目はこちら。）
20分の発表は話の構成のしかたがすごく難しいなと思った。今回はストーリー作りもそうだし、スライドでの伝え方に結構苦戦して、結局最終的なストーリーに行き着くまでに何回か潰した気がする。20分のボリューム感、どこまで話広げるべきかがわからなくて、結局最後の練習まで17分で終わってしまうボリュームだった（本番はなぜかぴったり20分になった）。
本番は小さい部屋でしたが、満員で部屋に入れなくなるほど人が来てくれたり、発表後に質問に来てくれた方もいた。発表してよかった。。。 ちょっと今後気をつけようとおもったのは、新しいmacとアダプター経由でのプロジェクターへの接続が悪くてヒヤッとした。やっぱりしばらく旧macも一緒にもってないと怖いかも。
あとは他のイベントと比べてtwitter実況が少ないイメージ。どんなところが刺さったんだろう？ちゃんと伝わってたかな、心配です。
また登壇後、コーディングスキルアップの仕方について後輩と話したりして、結局今回レビューしてくれていた先輩がすごかった＆かなり恵まれてたんだなぁということに気づく。 多分若手にとってもどんな知らない世界があるのかわからない、先輩にとっても若手がどこまで知らないのかわからない、このお互いの状態をつきあわす機会があって、うまく知識を整理してインプットしてくれる先輩がいて今回の内容に繋がったんだとおもった。 恵まれてる環境だったのは確かなんだが、より横展開しやすい形にできたらもっと良かったなと感じた。
あとは初めてはてなのホッテントリに入って感動！準備してる時は地獄だとおもったけど、こういうアウトプットにできて今回CfP出してみてよかった。
ちなみに2017年の目標は「社外のイベントで登壇する」にしていて、これで叶ってしまったのでまた新しい目標を立てるとする。 自分のアウトプットに反応が返ってくる意味で登壇するのすごくよかったので、これからも機会あったらどんどん出してこ！
社会人2年目をエモめに振り返る
エンジニアとして2年めが終わったので振り返り。今思うことは今書いておかないと忘れちゃう。あと根がネガティブなので記しておかないと「私1年何やってたんだろう・・・」とすぐなっちゃうので。
ちなみに1年目の振り返りエントリは以下。
今年度の主なトピックは以下。
が大きな出来事だったかと思います。
Androidアプリのエンハンス
1年目は新規アプリの開発がメイン&かなり短いスパンでチームを移動していたので、同じチームで一つのプロダクトを開発し続けるという経験は初めて。新規ではなくエンハンスをする中でただAndroidの実装スキル以上のことを学ぶきっかけになった気がする。
ライブラリの導入
今までのチームはモダンなライブラリをいれよう！という話があまりなかったので、今のチームに異動してきてから同じチームの先輩にはすごく刺激をもらった。
Realm、ActiveAndroid、Retrofit、などまだ使ったことなかったライブラリなどを、今年初めて触ったり。導入を進める先輩にライブラリの特徴・思想を聞いたり、何が便利なんだっけ？を考えたりするきっかけになった。特に先輩がRetrofitにプルリク送っているところを隣で見れたりして、すごく刺激になった。 その後、自分でチームにLightStreamAPIを導入したりできて、ちょっとだけチームのプロダクトどういう風にしていきたい？という気持ちが芽生えてきた気がする。 ライブラリを導入すると、何をどうやって便利にするライブラリなの？を考えるようになるので、自分で設計を考えるときにも参考になるなーと感じる。リスクの方が語られがちだったり学習コストなども考えるとライブラリの導入などはハードルが高かったりするけど、設計方針などのインプットにもなるのを考えるともっと導入すべきだなーとも思うようになった。
変更に強い・バグを生みにくい設計
先輩にココらへんの話のインプットはすごくしてもらった。あまり今まで設計のことを考えたことがなかった。正確にいうと、既にあるアーキテクチャに従う練習はちょっとしてきたけど、アーキテクチャを選択する練習をしてこなかった。なんでこういうアーキテクチャになっていてなぜそれを選ぶ？という観点がなかったので、そこを養えたのはよかった。デザパタとかクリーンアーキテクチャの話とかなどなど。 以下の記事は色々インプットしてた時で整理してた頃。
あーちょっと恥ずかしくて見たくないエントリ…
テスト自動化
スクラムを再立ち上げした頃にユニットテストコードを書いていこうというルールになって初めてテストコードというのを書くことになった。 社内のアプリチームではテストコードを書いているチームがあまりなかったので良い経験になった。色々社内の先輩などに相談できる機会があったりなど、ただテスト自動化すごい！じゃなくてメリットやデメリット考えつつどう進めていったらよい？なことは考えるようになったかも。最初はデグレをなくしましょうという話からテスト自動化の話が始まった気がするけど、設計やリファクタの話につながっていくところまで考えられるようになった。 かなりここの分野も楽しくてこれからももっと知りたいなーと思ってる。
スクラムチームの再立ち上げ
スクラムチームをどう立ち上げてどうなったかはこちらのエントリで。
上のエントリに書いたとおりスクラムチームの再立ち上げを2回経験していて。2回やってようやくスクラムの良さみたいのを感じれた気がする。すごく今はアジャイルの考え方の虜になっていてここの分野ももっと知りたいなと思っている。 元がコミュ障で人の言うことをすごく気にしてしまうので、チームの環境によって自分のキャラを出せなかったりパフォーマンスも左右されてしまうんですよね。そういうところをスクラムとかのアジャイルフレームワークは多少でもカバーしてくれる気がしている。なので自分にはすごく合っていたのかも？と思ってる。
コーチの人に言われたことで印象に残っているのは 「問題解決は簡単だ、解決方法はいろんなひとが試しているからそこらじゅうに転がってる。大事なのは問題発見する能力。ここが長けている方が価値の高いことなんだよ」 というようなことを言われたこと。問題発見したからやばい、もうダメなチームだ、じゃなくて問題が見つかったってことは今まで見つからなかったことが問題として見つかったのは良いこととポジティブに言われたことが自分の中でも改善に対する捉え方が変わった出来事だったと思う。
プライベートでのアプリ開発
2年目になって1年目のように資格勉強に時間取られることもなくなったので、プライベートでサービス開発しているチームにjoinしました。Androidアプリ作りたいけどちょうど人がいないという時に誘ってもらって、タイミング良かった。 これまで社外でこういったコミュニティがなかったので、違う会社の話を聞けたり視野も広がったり。
業務で試せてないライブラリやツールを試せる機会になったり、業務とプライベート複数同時にプロジェクトを進められる良さを知れた。一つ自分が作ったプロダクトができたのもうれしい。 その後自分一人でもう一個アプリ作ってみたのも勉強になった。CI自分で回したり自分でストアにあげたり。アイコンも自分で作ったり。自分が作ると他のアプリも注意深く見るようになるなー。自分だけでやってるので放置になりがちなのが反省点。
外部イベントへの参加
これも2年目になって業務都合をつけやすくなったので、ちょこちょこ外部のイベントにも参加するように。同じ年代の人がLT登壇とかしていてやばい！！！と良い刺激にも。
去年も行きたかったけど行けなかったDroidKaigiにも今年初参加！ 他の会社がどんなことに取り組んでいるのか、最新技術等やっぱり行かないとわからないことがたくさんでとてもよかった。登壇にも挑戦してみたいなぁ。
今年はDroidKaigiの公式アプリにもコントリビュートすることを目標にしていて、本当にちっっちゃなBugFixだけど英語でプルリク出してみたり。いつもtwitterで見るアイコンの人がコード見てくれて当日のContributersスライドにアイコンが載ったり。かなりうれしかった出来事。
今年度の最後にはJJUG CCCの登壇も決まり準備をそろそろ始めなきゃという感じ。去年はおっかなくて周りの人に投票なんてお願いできなかったけど、背中を押してくれる先輩もできて、いろんなコミュニティに投票をお願いできたり、良い関係のコミュニティが増えたんだなぁと感じて、前向きに色々がんばれてるなと思う。
その他
そういえば応用取ったし次は高度受けるかっつってネスペを受けたけど午後で落ちた。情報処理試験はいつも勉強がつらい。
後はちょっとしたクリエイティブ。
後は会社でOSS勉強会なるものに参加したり(先輩のコードでnodeにプルリク送ってみたり)、外部の会社のエンジニアとTDD的な勉強会でGo触ったり。 刺激！な1年だったのかも。
まとめ
会社の先輩にこんなこと言われたのが印象的でそう信じてる言葉。
「エンジニアはやればやる程知らない事が増えていく。知らない事が減るってことは成長していないということだから、知らないことが増えていくことは良いことだと思って！」
この1年も色々新しい世界を知れて楽しかった！特に周りの人には恵まれていたなと思っていて、良いまさかりをたくさんもらえたなー。相談できる人も増えたしかなりのびのびやらせてもらえたと思っている。まだまだ技術力は低いと言われているのが悔しいところで、そこはこれからも伸ばしていきたいところ。
今年は取り組んできたことをブログなりなんなりにアウトプットすることを重視してきた気がする。ちょっとブログを読んでくれる人が増えたりして、自分のことを知ってくれる人がいるのはうれしいなーと思ったり。あと精神安定的にも◎。 今年は、ブログだけじゃなくてもっとコード書いてアウトプットしなきゃな。
次はどんな1年になるんだろう！3年目もがんばるぞー！
テストについて相談しにいった内容をまとめる
チームのテストについての進め方についてアドバイスをもらう機会があり、これからの進め方についても参考になったのでまとめる。
前提・背景
- アプリ開発チーム。
- Model,Controllerは必須で単体テストを書くというルールで開発している。
- 振る舞いテストも一部コード化してリリース前に自動で回している。
今のチームでの課題
- 単体テスト書いてきたが、なかなかメリットが享受できていない気がする
- ふるまいテスト書いてみたはいいが、この先どう展開していくのが良いのだろう？
- viewにビジネスロジックが積まれていてなかなかテストが書けない。構造見直ししたいがアーキテクチャの指針なくできない。
viewにビジネスロジック問題
viewにビジネスロジックが書かれていてテスト書きづらい。 どうにかしたいが、リファクタするにはテストがいる。 じゃあテスト書きたいけど書きづらい！の堂々めぐりになってしまう問題。
実装の構造に依存する・実装に近いテスト（例：ユニットテスト）は書きづらいので、実装から遠いテスト(例：ふるまいテスト）を書いてリファクタする準備をまずしましょう、というのが次のアクション。なるほど！
振る舞いテストで安心してリファクタできるようになれるのか
たしかに、怖くてリファクタできない！けど構造変えなくては！の打ちてに対して実装に依存しないようなシステムの外からのテストを書けばよい！というところには納得。 現状、今のチームではアプリをリリースする前に毎回行っているアプリの根幹の機能(主に遷移周り)のテストを書いている。でも、粒度もすごく大きいテストケースなので、それで安心してリファクタできるイメージが湧きません！
それに対してのアクションは、まずカバレッジをとりましょう。まずどこがカバーされているテストがあるのか、どこのコードが通っているテストがあるのかを可視化する必要がある。テストが通っているところから構造変えていくようにすればよい。
この話をふまえると、これから構造よくしていきたいところにユニットテストを書いていくより、ふるまいテストの拡充を優先度を上げた方がいいのだろうな。まずは外から、だんだん中に入っていってカバレッジなどをあげていく。 今までカバレッジなどは気にしないで「書けるところを書いていこう」の指針でずっと来てしまったので、きちんと数値とっていかないとダメですね。
振る舞いテスト(≒スモークテスト）の運用
今チームの中で振る舞いテストと言ってるものは「スモークテスト」と呼ばれる「このテストが落ちると、リリースしてはいけないというレベルのもの」になる。 このスモークテストを今までリリース前に最後のチェックとして行ってきた。本当はリリース前に煙が出てもしょうがないので、普段から本当は回すべき。プルリクがマージされた時などに自動でテストが回るような仕組みにしておくと早めに重大な問題に気づくことができてGood!
アーキテクチャ決まってない問題
アーキテクチャに関しては最初は「王道なもの」を採用してやってみると良い。同じ挑戦している人の人数も多いし、ぶつかった人も多いので、導入もしやすいだろう。MVPならMVPと決めてやってみると処理を書く場所があらかじめ決まっているのでテスト書かなきゃいけない処理も決まってくる。一回入れてみて問題が出てきたらまた考えても遅くなさそう。
[おまけ]テスト自体は品質をあげるものではない
テストコードを書くこと自体は 品質をあげるものではない。 テストコードを書くことで、プロダクションコードに影響を与える（リファクタできれいになる、使いやすいように引数の種類変えてみようかとか）ことで品質があがっていく。なので、テストコード書いてプロダクションコードが変わらないのは別に品質あげてないよ。もちろんデグレを防ぐみたいな役割もあるかもしれないけど、品質はあがってないよね、下げるのを防いではいるけど。 という思想があるので、テストファーストに越したことはないが、テストファーストをするためにはプロダクトの実装の仕方（構造が悪いとか）にも寄るしある程度のスキルが必要なので、テストファーストにこだわらなくてもよい。大事なのはプロダクションコードにプラスの影響を与えられているか。
[おまけ]mock使う派？使わない派？
テスト駆動開発界には流派が2つあるらしく、mock使う派(テストは分離した方がよい）と使わない派(本物のデータを使う方がよい)とがいるらしい。
mockする派
テストしたいクラスを狭めることができる。mockしていなかったら依存しているクラスの中もテストしていることになるけど、mockすると純粋にそのクラスのロジックをテストできる
mockしない派
自作自演のテストになる可能性がある。mockしている実体が変わったら意味がなくなっちゃうから。テストは通るけど結合したらうまくいきませんーみたいなことが起きてしまう。 最近のmockライブラリは強力なので、なんでもできてしまう。そもそもmockが必要になるというのは設計としていかがなものか？を気づく基準にもなるけど、強いmockライブラリがいるとスルーしてしまう可能性。この話は先輩からも聞かされたなぁ〜。
さいごに
今までどう打ちてを打っていいかわからないところをアドバイスもらえて次の一手が見つかった気がする。テストの世界では当たり前の考え方なのかもしれないけど、ぺーぺーの自分にとってはすごく有益なアドバイスをいただける機会でした。
