Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
技術的負債に立ち向かうために テストを書いてる話
Search
レバレジーズTechアカウント
January 21, 2024
Technology
0
120
技術的負債に立ち向かうために テストを書いてる話
## 技術
テスト、単体テスト、統合テスト、技術的負債、単体テストの考え方/使い方、偶発的な複雑さ、本質的な複雑さ
レバレジーズTechアカウント
January 21, 2024
Tweet
Share
More Decks by レバレジーズTechアカウント
See All by レバレジーズTechアカウント
デザインシステム基盤構築実践
leveragestech
1
2k
荒廃したテックブログの再生_技術広報LT大会
leveragestech
4
5.5k
文系大学生と学び考える開発生産性
leveragestech
1
27
「マイクロサービスアーキテクチャ」と「アーキテクチャ特性」で読み解くレバテックのこれまでとこれから
leveragestech
0
50
社内共通ルールを値オブジェクトにして社内ライブラリとして運用してみた話
leveragestech
7
2.9k
Effect-TSを利用した副作用を分離する設計について
leveragestech
0
870
マネジメント未経験の脳筋が開発チームのリーダーになって感じた苦悩と学び
leveragestech
0
82
モノリス改善史~運用改善とバージョンアップの軌跡~
leveragestech
0
29
CREって何? CREが生まれた背景と、自社の事例
leveragestech
0
54
Other Decks in Technology
See All in Technology
【基本】データベース設計
oracle4engineer
PRO
2
250
高専で制御を、大学でセンシングを学び、次は脳みそ
satoshirobatofujimoto
0
120
M5と自作基板をくっつけてみた〜M5 Japan Tour 2024 Spring 福冈 (Fukuoka|福岡)〜
keropiyo
0
210
「知的単純作業」を自動化する、地に足の着いた大規模言語モデル (LLM) の活用
nrryuya
0
510
地理空間データ可視化・解析・活用ソリューション Pacific Spatial Solutions (PSS)
pacificspatialsolutions
0
350
成長をサポートするピープルマネジメントのやり方
sioncojp
9
1.4k
Google Cloud Next '24 Recap(Cloud Run/k8s)
mokocm
0
370
AWSやJAWS-UGとの出会いを振り返る
yoyoyopg
1
160
【SORACOM UG 東海】あらゆるモノがつながる社会へ、IoT と SORACOM
soracom
PRO
1
160
【NW X Security JAWS#3】L3-4:AWS環境のIPv6移行に向けて知っておきたいこと
shotashiratori
1
710
競技としてのKaggle、役に立つKaggle
yu4u
7
2.4k
Handling focus in 2024
tahia910
0
440
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
26
5.8k
Infographics Made Easy
chrislema
238
18k
Thoughts on Productivity
jonyablonski
60
3.9k
Creatively Recalculating Your Daily Design Routine
revolveconf
211
11k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
51k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
155
14k
Fashionably flexible responsive web design (full day workshop)
malarkey
398
65k
The Invisible Customer
myddelton
114
12k
10 Git Anti Patterns You Should be Aware of
lemiorhan
649
58k
Large-scale JavaScript Application Architecture
addyosmani
504
110k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.7k
The Cost Of JavaScript in 2023
addyosmani
21
3.9k
Transcript
技術的負債に立ち向かうために テストを書いてる話 レバテック開発部 前原 宗太朗
| © Leverages inc. 2 自己紹介 お名前 前原宗太朗 所属 レバテック開発部 /
BSD第1開発部 趣味 世界で大人気なゲーム League of Legendsの動画を 見ること
| © Leverages inc. 3 アジェンダ • なぜテストを書くのか • EntrySyncにおけるテストの課題と工夫
1. なぜテストを書くのか
| © Leverages inc. 5 なぜテストを書くのか 社内でテストの重要性が認知されつつある • 社内勉強会 ◦ 単体テストの考え方
/使い方 • レバレジーズテックフェス 2023春のテーマ ◦ 「急がば品質。ワンランク上のレバクオリティへ」 • インシデントの増加 ◦ チーム内でテストを書こうとなったきっかけも 障害から ◦ 複数チームを巻き込む、データリペア作業もあり きっかけこそインシデントだが、テストを書く意義についてもう少し考えてみる Vladimir Khorikov (著), 須田智之 (翻訳) 単体テストの考え方 /使い方
| © Leverages inc. 6 なぜテストを書くのか 積み上げられた仕様 • 改修に改修を重ねたシステムで、正しい仕様の把握が難しい データの項目が多い •
100超えるテーブルもあり、テストケースを用意するのが大変 • どの項目を変化させると、何が変わるのか把握が難しい 連携するシステムが多く、データやビジネスロジックが密に結合している • 業務システムのAPIでデータを取得してビジネスロジックを組み、再度 APIで更新を行っている • 他サービスを立ち上げないといけないので、真面目に取り組もうとすると面倒なことが多すぎる システムの負債が積み重なり、ちょっとした改善でも腰が重いと感じてしまう 重要性は理解している。それでもテストを書くのは腰が重い
| © Leverages inc. 7 なぜテストを書くのか 一人歩きする技術的負債という言葉 技術的負債という言葉はどこか抽象的 リファクタしたい、1から作り直しリニューアルをしたい という声をよく聞くが 、何が問題なのかわからないままリファクタを行っても状況は良くならない
負債を解消するために、まずは負債に対する解像度をあげる必要がある
| © Leverages inc. 8 なぜテストを書くのか ソフトウェアの複雑さには2種類ある 偶発的な複雑さ いわゆる実装の都合によるもの 命名規則やアーキテクチャパターンなどを含む 本質的な複雑さ
問題空間に潜むソフトウェアそのものの複雑さ ソフトウェアの複雑性は本質的な性質であって、偶有的なものではない 複雑性を取り去ったソフトウェア実体の記述は、しばしばその本質も取り去ることになる。 引用 フレデリック・ P・ブルックス , Jr. 著 ピアソン・エディケーション『人月の神話 新装版』
| © Leverages inc. 9 なぜテストを書くのか ソフトウェアの複雑さには2種類ある 偶発的な複雑さ いわゆる実装の都合によるもの 命名規則やアーキテクチャパターンなどを含む 本質的な複雑さ
問題空間に潜むソフトウェアそのものの複雑さ 技術的負債を解消したいと口にした時、偶発的複雑さを指すことが多い しかし本質的な複雑さを軽減しない限り、問題空間全体の複雑さは減らない
| © Leverages inc. 10 なぜテストを書くのか 本質的な複雑さはどうやって減らすのか 問題を分割して考える = 複雑に混じり合った概念を分離する そのために、仕様の直交性に注目する
引用 スケールする要求を支える仕様の「意図」と「直交性」 https://qiita.com/hirokidaichi/items/61ad129eae43771d0fc3#%E4%BB%95%E6%A7%98%E3%81%AE%E7%9B%B4%E4%BA%A4%E6%80%A7 The Art of Unix Programming http://www.catb.org/~esr/writings/taoup/html/ch04s02.html#orthogonality 2つの機能は直交している = 2つの機能が無関係に動作すること モニターには直交コントロールがあります。コントラストレベルに関係なく明るさを変更でき、(モニターに 1つある場合)カ ラーバランスコントロールは両方に依存しません。明るさのノブがカラーバランスに影響を与えるモニターを調整するのが どれほど難しいか想像してみてください。明るさを変更した後は、毎回カラーバランスを調整して補正する必要がありま す。 問題空間全体の複雑さは変わらないが、個別の問題で見た時の複雑さは軽減される
| © Leverages inc. 11 複雑さの正体が分からないと1つの大きな複雑さの塊に見えてしまう 我々は正体不明な複雑性に対して、技術的負債という言葉で片付けてしまう あくまで個人的な見解ですが リプレースは偶発的複雑性を軽減するものでしかなく、本質的な複雑さは軽減されない 複雑に混じり合った概念を分離しない限り、リニューアルをしても本質的な複雑さが軽減されることはない ソフトウェアの本質は複雑さであり、この複雑さに立ち向かいたい
しかし偶発的な複雑さに圧倒されてしまって、本質的な複雑さに立ち向かえずにいる なぜテストを書くのか 1つの大きな複雑さに見えてしまう問題(自戒をこめて) 文字文字してすみません。。。
| © Leverages inc. 12 本質的な複雑さと偶発的な複雑さを同時に対処するのは難しい 偶発的な複雑さを減らした上で、本質的な複雑さに立ち向かいたい そのために継続的改善は必要だし、継続的改善のために既存の資産にもテストが必要 なぜテストを書くのか 複雑さに立ち向かうのは難しい(主観) 文字文字してすみません。。。
2. EntrySyncにおける テストの課題と工夫
| © Leverages inc. 14 我々の扱うシステム オウンドメディア ※ 他にもありますが詳細は割愛 プラットフォーム サブシステム
社内業務システム • 社内業務システムやプラットフォームを支える ための各種マイクロサービス • エージェント業務遂行のためのシステム • 面談や推薦の管理を行う • 求人の閲覧や応募、エージェントの申し込みな ど • ユーザーのマイページ • 求人の応募や作業報告書、請求書の管理など
| © Leverages inc. 15 我々の扱うシステム オウンドメディア ※ 他にもありますが詳細は割愛 プラットフォーム サブシステム
社内業務システム • 社内業務システムやプラットフォームを支える ための各種マイクロサービス • エージェント業務遂行のためのシステム • 面談や推薦の管理を行う • 求人の閲覧や応募、エージェントの申し込みな ど • ユーザーのマイページ • 求人の応募や作業報告書、請求書の管理など EntrySyncとはオウンドメディアと社内業務システムを繋ぐサブシステム
| © Leverages inc. 16 EntrySyncにおけるテストの課題と工夫 オウンドメディアから応募した求職者情報を社内業務システムに連携 オウンドメディアB オウンドメディアA プラットフォーム EntrySync
社内業務システム DB ① 流入情報をDBに保存 ② 流入情報を取得 ③ 営業情報を取得 ⑤ 営業情報を更新 ④ 2、3の情報を元に重複判定 のビジネスロジック
| © Leverages inc. 17 EntrySyncにおけるテストの課題と工夫 EntrySyncでテストを書く上で辛いポイント オウンドメディアB オウンドメディアA プラットフォーム EntrySync
社内業務システム DB ① 流入情報をDBに保存 ② 流入情報を取得 ③ 営業情報を取得 ⑤ 営業情報を更新 ④ 2、3の情報を元に重複判定 のビジネスロジック データを作ってるのが別システム ビジネスロジックのために別システムに問 い合わせが必要 テストで確認したい結果も別システム メディアごとに別のパラメタを持つが、全て 同じテーブルに保存される
| © Leverages inc. 18 認知負荷が高いと感じる • データの項目の数が多い • 確認しないといけないテストの数も多いと感じる 他のアプリケーションとの連携が面倒
• 他のアプリケーションをいい感じに立ち上げないといけない • 初期設定や初期データを用意してあげないといけない これ全てやるのは大変そう、道筋が遠くて腰が重くなる EntrySyncにおけるテストの課題と工夫 “腰が重い状態”を脱したいので、腰が重くなる原因を考える
| © Leverages inc. 19 一つのことに集中して認知負荷を下げる • テストのコンテキストに不要なものはできるだけ隠蔽する ◦ よくよくコードを読むと1つのテストケースに影響する変数はそこまで多くない •
1つのテストで1つのことしか確認しない 複数サービスとの連携は妥協している部分が多い • 本当は複数サービスを立ち上げて CIでe2eとかしたい • まずはローカルで動かせるところから始める EntrySyncにおけるテストの課題と工夫 テストがない状態から、テストがある状態にするのが最重要
| © Leverages inc. 20 一見テストデータの項目数が多くとも、1つのテストケースに影響を与える項目はそう多くはない テスト結果に影響する項目以外はデフォルト値を与えることで、テストに作用する項目がわかりやすくなる EntrySyncにおけるテストの課題と工夫 テストのコンテキストに不要なものは隠蔽する
| © Leverages inc. 21 EntrySyncにおけるテストの課題と工夫 テストの書き方によって認知負荷を軽減する Arrange-Act-Assertパターンによるテストの記述 • テストのフォーマットを準備、実行、結果の確認のフォーマットで記述する •
フォーマットが統一されることでテストを読む際の認知負荷が軽減される 1つのテストでは一つのことしか確認しない • 複数のAssertを1つのテストケースで確認したくなる • 特にArrange-Actが同じ場合はコードを再利用したくなる • 全体の冗長性を許容しても、1つあたりのテストケースの認知負荷を下げる
| © Leverages inc. 22 EntrySyncにおけるテストの課題と工夫 結果として、1つのテストケースが1画面に収まるため視認性が良い
| © Leverages inc. 23 EntrySyncにおけるテストの課題と工夫 他のアプリケーションとの連携 オウンドメディ アB オウンドメディ アA
プラットフォー ム EntrySync 社内業務シ ステム DB ① 流入情報をDBに保存 ② 流入情報を取得 ③ 営業情報を取得 ⑤ 営業情報を更新 ④ 2、3の情報を元に重複 判定のビジネスロジック 本当は全部のサービス起動して e2e なテストを実行したい 現実は全部の環境をシュッと立ち上 げれるほど整っていない 全部を整備するのは億劫
| © Leverages inc. 24 EntrySyncにおけるテストの課題と工夫 腰が重いポイント(再掲) オウンドメディ アB オウンドメディ アA
プラットフォー ム EntrySync 社内業務シ ステム DB ① 流入情報をDBに保存 ② 流入情報を取得 ③ 営業情報を取得 ⑤ 営業情報を更新 ④ 2、3の情報を元に重複 判定のビジネスロジック 他のアプリケーションをいい感じに立ち上げな いといけない ・一旦諦めて最低限ローカル動くことを目指す ・ある程度完成したら CIに移行 初期設定や初期データを用意してあげないと いけない ・ヘルパーを作って beforeAllで呼び出す
| © Leverages inc. 25 EntrySyncにおけるテストの課題と工夫 一部に絞って構築、まずは最低限ローカルで動くように オウンドメディ アB オウンドメディ アA
プラットフォー ム EntrySync 社内業務シ ステム DB ① 流入情報をDBに保存 ② 流入情報を取得 ③ 営業情報を取得 ⑤ 営業情報を更新 ④ 2、3の情報を元に重複 判定のビジネスロジック この部分に絞って構築 残りの環境はDB経由での依存になるためシ ステムを立ち上げる必要はない 初期データをSQLでDBに突っ込むだけでOK データを作る責務はオウンドメディアが持って いるので、そこに作らせたいが、 ここは妥協点
| © Leverages inc. 26 EntrySyncにおけるテストの課題と工夫 自サービスのデータは TypeORMのRepository経由 でEntityを指定して削除 他サービスは最低限のテーブル削除 データの初期化は関数にまとめて、
beforeAllで呼び出す ※ 後日気がついたことですが他サービスでもちょうどテストを書いていて、 最低限のデータを含む Dumpを用意されていたので、今後はそっちを使う予定です サービス単位でこういうのが整備されていると嬉しいですね
| © Leverages inc. 27 まとめ • ソフトウェアには本質的な複雑さと偶発的な複雑さがある ◦ 本質的複雑さに対処するためにも、継続的改善で偶発的な複雑さを減らしていこう ◦
そのために既存の資産にもテスト書いていこう • テストを書こうにも複雑さにやられて嫌になってしまうこともある ◦ 本質的な複雑さは減らせないので、 偶発的な複雑さを積極的に解消していこう
| © Leverages inc. 28 今後 • 負債が溜まっているシステムにテストを書いただけ だと、テストそのものの認知負荷が高く負債となって しまう ◦
テストによってリファクタ耐性がついたので、コードを綺麗にするようなリファクタリングを行う ◦ さらに本質的な複雑さに立ち向かうために概念の分離を行う