■anond:20240416095040

テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。

OSの保守なら無いのはおかしいだろう

GでもCでもUIはまた別

結論としては書かないほうがいいと思った。

そういうこともある

テストを書くためのコストが小さいなんて妄想もいいところだ。クソデカである。

全然小さいというか書くためと変更のコストがクソデカなら何か間違ってる

結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。

Jenkins?jUnit等ではなくて？

100人以上かかわる巨大プロジェクトでも「テストコードを書かなかったので破綻した」、とかはなかった。

まあそれはないだろう

テストコードを書くと実装の見落としが見つかってありがたいことはあった。

テストが設計図だからね

デバッグするよりテスト書いたほうが早いことがあった。

それはデバッグの一環のような

git pushするたびに毎回走っても全くの無意味だった。

無意味なものを流してはいけない

テスト対象が変わるとテストを書き直さないといけないのがサイアクだった。非効率化の極みだ。人生の無駄。

一番よくあるやつ

そこのバランス考えないと

バックエンドのビジネスロジックを担当するがっちり仕様が決まっていて勝手に変更されてはいけないものなんかをやる

UIの場所が変わって破綻するようなのは大概はしない方がいい

その次にサイアクだったのは、テストコードの実行が失敗したときテストコードのバグであることが大半であったことだ。

コードのパーツがでかいのでは？

GUIソフトとテストコードは相性が悪いが、そもそも世の中のソフトウェア開発の大半はGUI開発である。

悪いね

テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。

例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると

メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。

DIはSOLIDに入ってるくらいで基本だし今時のフレームワークなら普通に使うよね

上にも書いたけどパーツがでかいのでは？って「直感的でない長くて複雑なプログラムになっている」とのことなのでやっぱりでかいんだろう

その辺はOOのやり方の問題じゃないかな

ふつ～に古典的なデバッグをすればいいと思う。

デバッグというか手動テストの話かな？

テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。

要件が固まらない、毎週変わるようなのとか、システムが絡むテストでコストが凄く高いもの、UIのマイナーな変更なんかは書かない方がいいけど

バックエンドのビジネスロジックなど書いた方が絶対にいいものもある

テストコードをやめた方がシンプルというのはわからないな

ものすごくシンプルな小さな一機能にしてそれに対するシンプルなテストを書くものだと思うけど

Permalink | 記事への反応(0) | 10:05

ツイートシェア