  |
はてなキーワード: GITとは
ネット上ではテストコードを書かないのは低レベルな開発者という風潮だ。
10年以上、テストコードを書く開発と書かない開発の両方を経験してきた。
■前提
・テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
結論としては書かないほうがいいと思った。
・テストを書くためのコストが小さいなんて妄想もいいところだ。クソデカである。
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
・100人以上かかわる巨大プロジェクトでも「テストコードを書かなかったので破綻した」、とかはなかった。
・テストコードを書くと実装の見落としが見つかってありがたいことはあった。
・git pushするたびに毎回走っても全くの無意味だった。
・テスト対象が変わるとテストを書き直さないといけないのがサイアクだった。非効率化の極みだ。人生の無駄。
・その次にサイアクだったのは、テストコードの実行が失敗したときテストコードのバグであることが大半であったことだ。
・GUIソフトとテストコードは相性が悪いが、そもそも世の中のソフトウェア開発の大半はGUI開発である。
・テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
「昔のプルリクをマージしようとしたらなんかコンフリクトしてたから、ブランチ元のバージョンまで戻してマージしといたよ。テストしといてね」
てめーふざけんじゃねーぞ
ブランチ元から今まで入れてたプルリクが全部ぶっとんだじゃねーかアホかよ
しかも大してGit知らんくせになんでそんなことできるの？って思ったらChatGPTに聞いて教えて貰ってるじゃねーかクソが
「コンフリクトしてるからバージョン戻してマージしようと思うけどどうするか教えて？」
とか聞かれたら
とか聞けよ
ちなみにこいつは昔、自分でmainブランチに勝手に変更入れたせいで他のブランチがマージできなくなって
「今後はfeature/hogeをmainブランチとする！」
そのときに部下から怒られたから「mainブランチを変えちゃだめかぁ。。。なら前のバージョンにマージすれば解決！」とかやったんだろアホがよ
知らないなら聞けばいいだけなのになんで聞かないんだよクソが
