実行環境依存のコードに対してテストを書く考え方

社内用の啓発記事ですが、閉じる理由がないのでここに投げます。 ブラウザにべったりなコードを書いてると、ブラウザや node.js 固有の環境をインラインで記述してしまうことが多々あると思います。 あえてダメダメなブラウザ向けのエントリポイントの例を書きます。 // main.ts let id = localStorage.get('id'); if (!id) { id = `${navigator.userAgent}-${Math.random()}`; localStorage.set('id', id); fetch('/auth', { method: 'POST', credentials: 'include', body: JSON.stringify({ id, at: Date.now(), }), headers: {'Content-Type': 'applicat

[ko-ya-ma]

とても良い内容。ただこれを読んで理解できる人は既に読む必要がない段階まで行っていそう。噛み砕いて説明しながら一緒にリファクタリングする勉強会が必要なんだろうなぁ…

[mizchi]

書いた。社内用のドキュメントだけど一般的なブラウザ用コードのテストの書き方

[n314]

クライアントサイドはよく分からないけど、MVCフレームワークのリクエストを処理するチェーンに似てるね。そういうレベルがアプリ開発者に要求されるのか。

[shingo-sasaki-0529]

間違った　DRYに心当たりがありすぎる〜〜〜

[mumei-0]

“実は最新の node v17 には fetch が実装されているのですが…”

[mapawata]

test()って普通に使えるの？あとで調べなきゃ

[ssids]

実行環境依存のコードに対してテストを書く、というより、テストできる実行環境依存のコードを書く、なのかな

[uva]

「初期にどれだけ意識高く設計したとしても、それはチームとして共有しないと意味ない」

[turanukimaru]

Clean Architecture というかアーキテクチャ設計はちゃんとやるとややこしい話以前にテストがしやすくなるんだよね。話がややこしくなる層に依存しないってことだから。

[yarumato]

“ブラウザ向けコードを書いてる。あえてダメダメな例を書きます。テストを実施する視点でいくつか問題があります。修正方法：起動プロセスを外部から制御可能に。副作用を分離する。”

[auient]

とても分かりやすくてありがたい。/ 『「環境(ここではブラウザ)のための抽象」と「ドメインのための実装」を同時に行わない、というポリシーが有効』