01:28:36
icon

はーあずにゃん

09:59:18
icon

いきなり寒くなって温度差で凍死した

16:50:09
icon

天一食べたくなってきた

17:37:45
icon

logseqってタグのDBはストレージに保存せず毎回オンメモリに作ってるのか?

17:40:14
icon

いやキャッシュとしてリポジトリとは別に保存してるのか

18:03:06
icon

Attach image
18:59:56
icon

自動車用のファブリーズ置いてみたら匂いが思ったより強くて厳しい

19:27:26
icon

ド級のスターミーナツ

20:48:03
icon

@charsiuCat I/Fの公開度とか副作用の有無みたいな外形的な基準でテスト対象かどうかを判断すると訳分からなくなりがちなので、なぜテストを書くのかの原点に戻って、とにかく壊れたらヤバいロジックをカバーすることを第一目標にする(重要度が低いとこは最悪諦める)のが結局一番良いという気持ちになっています

20:53:55
icon

仕様書がない、というか一般に関数やモジュールのinvariantを定義してないならテスト不可です

20:56:37
icon

privateなメソッドにテストを書くなというやつ不勉強ながら原典を知らないんだけど、おそらく元々は「書くな」とは言ってなくて、privateメソッドをテストしただけで公開I/Fがテストされたと思うなよ?の意味なんじゃないかと思っています

21:03:26
icon

プログラムの壊れ方をいろいろ見たことがないと何をテストすればいいのか分からないというのはありそう

21:07:50
icon

個人的にはだいたい「対象になる関数やロジックのinvariantを一息で説明できなければテストを書いた方がいい」くらいの基準でやっています

21:09:45
icon

invariantというかcontract?プログラミング文脈での使い分けがよく分かっていない

21:15:37
icon

Genericsの話題で出てくるinvariant/covariant/contravariantって元々どの分野の言葉なんだろう

21:16:11
icon

確かに圏論っぽさはある

21:16:54
icon

デブ……

21:21:09
icon

だいたいとしぁのせい了解

21:33:47
icon

Perk :itiiti_hitono_icon_no_file_mei_mirutoka_teokure_desune: 取ったらとにかくておくれそう