Weitere ähnliche Inhalte
Ähnlich wie Njug 20180414 (6)
Hinweis der Redaktion
- TISって会社から現職へ。T時代はアーキテクト、今プログラマ。
雑にアウトプットしてます
- 触ってみたい人ようにローカルPCにクラスタ環境を構築するためのプレイブック作ったよー。
git cloneしてvagrant up叩くだけ(vagrantが動く環境なら)
- プロダクトファースト的なところがあるのと、単純にテストコード書きづらい構成になってるから、書きやすい場所以外は書いてないです。
OOPだったり関数型だったり、っていうパラダイムの理解がまだ足りてないので、いきなりそういうことして引っかき廻すのもアレなので一旦大人しくしてる。
まぁ自分のことは棚に上げて言います。
- 私は過去こんな経験をしました
- DBがチームメンバーで共通
自分のデータが汚されるから、再現性が気が付くとなくなってる
- 無理やりカバレッジを上げた方が返って品質が悪くなるらしい。
カバレッジ通すためにコード改変された人が居るらしい
- 機能の改修するときにテストコードが動かないと、それを直さないとイケない(まじ死ね)
メンテしないくせに、動かないことが判ると動くようにしろとか言ってくるから、テストコード無い方が負債が少ない。(死ねば良い)
- 半分くらいは冗談で、テストコードは、、
- 2個目以降はチョットしたTIPS
・void以外
アウトがないと途端にテストしづらくなる
・状態を変えない
状態を持つ部分と処理をする部分のクラスは分けて書くとスッキリする。
これをやらないと、特定のINに対するOUTの処理が書きづらい。
これは、メソッドの中で状態によって処理分岐されてしまうことによって、テストケースが膨大化するし、中身見ないとどんなINを与えないといけないか判らなくてつらいから。
状態によって使うメソッドを分ける方が簡潔になる
- :85%
85%は正常系全部と、想定しているエラー処理を通す程度の割合。
:カバレッジの変化
コードいじる→緑にするのは当たり前で、周辺機能のカバレッジに変化が起きたかを気にする。
自分が触った部分以外のコードに変化が起きた場合、周辺機能に影響が出ていることを意味する
- ・全体を自動テスト
個人のPCで全てをやるのはツライし、それは意味がない
全体を自動でテストするようにセットアップする。
つまり、CIをやる
・コミット、プルリク
・自動で動くようにする
CIと連携させてSCMリポジトリのイベントをCIにフックさせる
手でやる、みたいなのは絶対にやらないから、必ず自動化する
- CIはパイプラインが使えるものが好ましいし、クラウドのサービス使えるならそれを使った方が良いです。
パフォーマンスどうこう言われてメンテしないといけないのダルイので。。
- 昔書いといて自分の口では外部に向かって紹介したことないから一応しときます・・・
- Elmハンズオン初開催、初心者歓迎!是非来てね!
- 自社のみ勤務なので客先常駐したくない皆さんのご応募をお待ちしております。