「単体テストを手動で行いエビデンス取る」の破壊力
単体テストは自動化するものだと思っていたから
一瞬何を言っているのかわからなかった 英語を入力して、日本語が出力されるのを確認、じゃないの ナウなヤングはステートを持たないコーディングがバカウケでしょ?
DBに持たせてアプリケーションサーバには持たせない 言語変更の問題なら、
すべきテストは異なる環境を網羅した横展開のテストだけど、
>>1の指摘なら、全く同じ環境なのに手動で1000回試行しろと命じられる縦に掘っていくテスト >>656
純粋に関数型を突き詰めるなら状態が必要な部分は全部引数に追い出すのが正解じゃないかな
多言語対応必要なラベルは言語コンフィグ参照なんかせずに毎度文字列を受け取れってことだ
まあ流石にそれはきついだろうから文字列そのものじゃなく文字列を吐くモナドを受け取る形でもいいと思うけど >>661
ちゃんと読めよ
自動化してもテストケースは人間が作ってるから
テストケースも自動化しようぜ!っていうのがHypothesisっていうツールの役目だろ?
だから自動テスト自体を否定してるもんじゃないぞ
https://github.com/HypothesisWorks/hypothesis × 自動テストは効果がありません
○ テストケースを自動化することは効果がありません
https://hypothesis.works/ >>664
むしろ、従来の自動化程度では甘い。もっと自動化しようぜとしか読めないのだが。
てか、あんた、中学レベルの英語を読めないの? ニンゲンに金銭を注入することで自動的に作業させてます。 自動テストを実現できていれば
中身を他の言語で書き直しても
簡単に動作確認が取れるよな 開発環境言語とテスト環境言語は一緒でも良いけど
開発環境とテスト環境は一緒にしてると移行しにくいな
ソースにテスト埋め込めます(キリッ
っていう言語多いけどさ 全自動になったとしてさ
ルールは与えないといけないわけでしょ?
そのルールのデバッグできないの? 仕様書に書いてあることだけチェックすりゃいいわけで
仕様書の項目以上増えることはない >>672
CASEツールやらUMLコード生成やらもう何十年も前からそういったアプローチがあるけど全くスタンダードになってない。
唯一Matlab+Simulinkが自動車業界で流行ってるぐらいかな?
開発言語の進化こそあるにせよ結局仕様書の曖昧さを具体化するのはソースコードのみであるという事実は何も変わってない。 仕様書は結構曖昧に書かれている
その曖昧な仕様書をよんで、ここが曖昧ですと指摘できるAIが
実現できないと仕様書からコードは自動生成できるようにはならない
しかし曖昧な文章を理解できてかつ、曖昧な文章を曖昧だと指摘できるAIは作れるのかね? 仕様書が曖昧でも別に俺らは困らないよな
割と曖昧に組むこともできるし
会社の経営者層と俺らって一線引いてあること多いし
セキュリティが緩かったですなんて完全に他人事
客先常駐だったらそもそも仕様を決めたクソったれが悪いし
請負だったら出された要件を満たす項目だけ組むだけ
要件に最強のセキュリティとか書いてあったらできませんと返すことになるだろうが 仕様書から生成されたコードの動きをテストするのは
仕様の曖昧さとは関係ない
仕様に曖昧さがなくてもテストは必要 >>676
> 仕様書が曖昧でも別に俺らは困らないよな
プログラムに直すときに修正しているからね
コンピュータ(AI含む)はそれができないから
仕様書からのコードの自動生成なんて不可能 俺は単体テスト煽りの意見を支持する
単体テストは杓子定規な方便だよ
ネクタイと革靴の有無で大人度を判断するような本質からズレたまま根付いたスタンダード
まるで無駄とは言わんが、なくなった方が世界が少しシンプルになるやつだ テスト書いてないとかお前それ@t_wadaの前でも同じ事言えんの?(AA略 Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか?
Nimの実験的特徴 バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html
第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412
Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる
「怠け者とはこうあるべきだ!」と言うとても大事な事を Nim は我々に教えてくれます Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか?
Nimの実験的特徴 バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html
第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412
Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる
「怠け者とはこうあるべきだ!」と言うとても大事な事を Nim は我々に教えてくれます きれいなテストが書けるやつのコードは読みやすいよ
テストに工数がかかるし意味ないって言ってるやつはCLEANなコードが書けていないだけ おまえらテストいちいち自動化してんの?
マジでえらいな
おれ時間勿体無いしそんな時間あったらネットしたりしてたいから
手動でぱぱっと終わらして
仕様変更来ても関係なさそうな部分だったらテストしないわ >>692
> テストしてんの?テストしないわ
までよんだ なんだか20年くらい前にユースケース図が流行ったときに
全く役立たない棒人形ばかり仕様書に書いていた事を思い出した。
テストプログラムもユースケースと同じように書いてる本人も意味が分かっていないかも? テストプログラムがなんのことか知らないけど、
よく使われている有名なオープンソースソフトウェアには
かならずテストコードがありますよね?
テストコードの重要性は否定できないのでは?
ユースケースは殆ど見かけないけど >>695
ユースケース図のコピペと同じで
常にパスするテストコードばかりのプロジェクトも見たことある。
関係ないがその会社は他にも難があり
VisualSourceSafe(当時)みたいな履歴管理システムは分かりにくいから使うな。
クラスはトレースが困難だから使うのはやめるように
JavaのInterfece宣言がプライベードメソッドにだけされている。
DBでSelectした場合は必ずInsertした順序で出るから・・・
今でもこんなところがありそうなので怖い。 え?ユースケース図は今は書かないの?
要件定義ではいつも書いてるけど このスレ加齢臭すごいな
汎用系→WEB系に転職したけど
まさに汎用系の現場にいたようなやつらばかりだね
どうせアレだろ?「スクリプト言語は簡単!バカでも出来る!!」信仰なんだろ?
一生COBOLでPERFORM文でも書いとけや
金になるからって若手に変な仕事押し付けないでください。 これ「単体テストをしてるフリをするBOT」の需要あるだろ ユニットテストにエクセル生成のライブラリをくっつけたやつが有れば便利なんじゃないかと思ってる なんかAIがテストコードを生成してもおかしくない時代になってきたな 単体テストって改修した部分のコードをexcelに貼り付けて確認表を埋めるんだろ。知ってる。 単体テストの結果がおかしかったので修正しておきました!(テスト結果を) >>704
テストパラメータをズラズラ並べる時なんかはcopilotの補完がかなり利くね
テストデータを外出しにすると逆に補完が利きづらいから外出ししたくなくなるw