実データでプログラミングすれば単体テストは不要！
すげーや（笑）
https://www.usp-lab.com/methodology.html
開発方式の特徴： 一休さん方式
> 一休さんは、屏風に書かれた虎を見事捕まえてみよ、という難題を前に、
> 「さあ、すべて準備は整いました。私が虎を縄で縛りますから、虎を屏風から出してください。」
> という頓智で場を切り抜けた逸話がありますが、ユニケージは一休さんにならい、
> データという虎を見事捕まえるために、まずデータを全部出してもらうことを要求します。
何を言ってるのかさっぱり理解できない。俺が馬鹿なのか？
> さらに、実データを使ってプログラミングすることにより、
> 単純な動く動かないの単体テストはプログラミングの過程でクリアでき、開発効率も向上するのです。
すげーなー、実データがあれば単体テストが不要になるんだー
> ユニケージには、多くの「お作法」が存在し、ドキュメントの削減に寄与しています。
> 例えば「ワンプログラムワンフロー」の原則や、「アプリケーション固有のLEVEL4」の作法は、
> 複雑になりがちなプログラム間の相互関係の記述やテストを不要にしています。
シェルスクリプトは移植性低いからOSを変更したりバージョンアップした時に
動くかどうかわからないじゃん。テストしないとだめだよ。 セキュリティの考え方がないのかな？
個人情報盛りだくさんの実データを使ってテストするわけ無いじゃん > ソフトの仕様を固めて、ソフトを組んでから最後にデータを流すという回りくどいことをしません。
> 実データは仕様書よりも「現実的な」情報が多いのでユニケージは
> プロジェクト当初に要件定義より先に実データをすべて準備することに拘るのです。 > 実データは仕様書よりも「現実的な」情報が多いので
意味不。なんつーか、開発手法の穴を、屁理屈でごまかしてる感じしかしないな つーか、システム開発前に、どうやって実データを作るんだよって話
実データは別のシステムからもらえることが前提となってるのか？
そういう前提の開発手法というなら、適用できる用途が限られてることになる
実データがあったとして、じゃあ何が正しい計算結果なのか
どうやって判断するつもりだ？ロジックのテストは？
多数の実データから手計算と突き合わせて「うん、あってる！」みたいにやるのか？
実データ使って見つけられるバグは想定外のデータ形式とかで
実行時エラーが出ることぐらいなわけで
だからユニケージはバグが多くなってしまっている こいつらテスト仕様書とかも書いたこと無いんかな？
どういうデータでテストしますとか何も決めずに
実データで動けば動くだろみたいな
甘い考えでやってるのか？
プロ意識ないな ユニケージ開発手法（Enhanced UNIX）とは③
https://www.aibsc.jp/wp-content/uploads/2021/09/DX_AIBSC_USP.pdf
> ? ローコードAgile
>
> 生産性向上の手法としてのTPS
> →米国でシステム開発の生産性向上手法として
> 「アジャイル手法」に応?された
？？？
ローコード？？？
Agile？？？ 仕様を公開していないパッケージソフトだと、こういうシステムテストだけで終わらせているところはある。 データの仕様からダミーデータ起こすよね
機械学習させる前提なら知らんけど
時代はAIなのかな なんつーか、セミナーで
実データを使ってプログラミングすることにより、
単純な動く動かないの単体テストはプログラミングの過程で
クリアでき、開発効率も向上するのです。
とか言われたら、乾いた笑いしか出てこないわｗ > 単純な動く動かないの単体テスト
単体テストをコンパイルエラー相当のものと勘違いしてないか？
単体テストっていうのはモジュールとか関数レベルの小さなレベルで
正しく動くことを確認するテストのことだろ？
実データには含まれてないような稀なデータでもちゃんと動くように確認してさぁ
処理が間違っていても、単純に動けばOKみたいなもんじゃないぞ 将来的に更新されないデータしか扱わないということならそれでいいかもしれない 今更一休さんがナンセンスだという動画がつべのお薦めに上がってて？だったが
こいつらの影響か 30年前の手法が今も通用するし
これからも通用するのがユニケージ ところがユニケージは数年も持ちません
可搬性が悪く、保守性が皆無だからです データベース、SQLのテストをしない人間は、世代に関係なくいる。データ型が間違っていても気づかない。なぜか氏名の名字は2文字という決めつけのシステムを見たことがある。 決めつけというよりは
ディスクを節約したかったのでは? そんな節約してなんの意味があるの?
節約にならんよ 「五十嵐太郎」を例にすると姓が「五十」、名が「嵐太」となるシステムを見たことがある。 テストデータでテストしても実データで起こる問題は見つからない場合がある
実データでテストしても一見動いているように観えて問題が起こるパターンを漏らす可能性がめちゃくちゃ高い
つまり両方必要
以上おしまい >>32
重要なのはこれなんだ
> 実データを使ってプログラミングすることにより、
> 単純な動く動かないの単体テストはプログラミングの過程でクリアでき、 実データでテストするのはむしろ当たり前だろ
それをテスト環境に本番環境からデータをコピーしてきてやるんだろ
本番環境の実データでテストしろとは誰も言ってないωωω 単体テストで動く動かないしかテストしないと思ってるのが怖い >>34
そんな事書いてないぞ
実データでプログラミングすれば
単体テストはクリアできる
って言ってんだよ
実データでテストするとは書いていない メモリの確保サイズを確かめるには、実際に最大サイズを使わないとわからないからな。 UTF-8を使っているつもりが、SJISだったりしてもシステムテストレベルではわからないから LFとかCRLF前提で描いてると
CRのみというアホなコードが混ざって困るのが実データ 普通の人の感想はこれだよなぁ。
https://xtech.nikkei.com/it/article/NEWS/20080906/314276/
> 最初の題材は，旧システムから新システムへのデータ変換プログラムにミスがあり，
> 新システムのシステム・テスト中に問題が見つかった事例である。
> あらかじめ実データを使ってテストされていたことを受け，
> 大西氏は「システマチックにテストされていたのか疑問だ」と指摘した。
テストデータというのは
仕様に合わせてテストすべきないようを網羅したもの。
実データでプログラミングするだけで、単体テストがクリアとか言われても
ちゃんとテストすべきものを網羅しているのかなんてわからん
はぁーーーーー、ユニケージ開発手法は、根本的に「雑」
プロの仕事じゃない 実データでテストすること自体はいい
テストデータだって完璧じゃないし見逃しはある
だが実データを使ってプログラミングしてれば
動くっしょ？という考えは大問題
シェルスクリプトで業務システム開発じゃーって息巻いて
誰かにシェルスクリプトじゃ単体テストできないよね？って
突っ込まれた時の苦し紛れの言い訳にしか見えない
「実データを使ってプログラミングすれば、単純な動く動かないの
単体テストはプログラミングの過程でクリアできる！」
いや、単体テストは、単純な動く動かないをテストするもんじゃねーから マズい処理A
マズい処理B
が合体することで
結果として正しい結果になっている
効果を狙う匠の技 >>44
実際意図的にそんなコード書く人もいるからなぁ。
マズイ処理A
＋匠「なにぃ？まずい？そんなのこうやってああやれば修正できるだろ」
＝正しいと思えるような結果
結果だけ見ても正しくても
なんでマズイ処理やってるのに結果が正しいのかわからない
理由がわからないので、結果が正しくても責任が持てない
余計なことをした匠だけが自信満々 単体テストなんかする工数が無いのでテスト無しで普通に開発してたがそんな現場の方が多いだろ
テスト運用中に不具合潰して本番後も不具合分かったら潰す
これが俺流のアジャイル まあ、経験上やったほうが早く済む
っていうかできるような仕組みを心掛けるって感じ？ 何ならレビューすらめんどくさがられてバグがあったら俺のせい >>46
規模が小さくて、信頼性？知ったこっちゃねーよ
っていう所しか使えないけどね
SIって作りっぱなしで保守開発は客任せにするから
だからそんな事が成り立つ
客がいくら苦労しようが知ったこっちゃないという考え
自社サービスで長期間運営するとかには使えない
自分が苦しむからね データの仕様に沿ったプログラミングして本番データで間違い無いか確認出来たら安心
データの仕様が信用出来ないかも知れんし >>49
自社サービスではないけど保守運用は請け負っていたぞ
だから自分に返ってくるけど納期優先だから後にツケを回さずを得ない
少ないリソースでスピードが求められる現場だから理想通りには進められない 単体テストしないとスピードが落ちるじゃん
バカなの？
それともチキンレースしてるの？ テストコードを書く時間とテスト実行にかかる時間で何倍もかかる >>54
テスト項目数何件あるの？
1000件のテストを修正のたびに手動でやってられないんだが 問題はテストコード書く時間で十回は単体テストできることだな 手動派って一回しかテストしないですむのか、うらやましいな >>56
手動でやっていて毎日全体テストなんてできるんですか？
コード修正するたびにテストしなきゃ
責任なんて持てないでしょう？ >>59
やる必要がどこにあるんだ？
自動テストを作成する工数が高すぎるのが問題
変更コストとかそもそも元のテスト仕様がドキュメントになってなくてこれまたクソ
そんでテストの内容も仕様書のどっからこのテストができるのか？これまた謎
あとシステムもよくない
ロジックだけをテストできる仕組みを現在の自動テストは持ってない
そうなるとカバレッジいくつがという数字だけ一人歩きを始めてその数字を100%にすることに何の意味もないっていうね
このクソシステムもやりたくない理由の1つ
それと実際に時間がかかるところは結合テスト
単体に必要以上に時間をかけてる暇は今の開発にはないと思う
そんなわけで自動テストはゴミ
いつもこの話を持ってくるやつには
プロジェクトで1番でかいメソッドの自動テストを組んでもらってお引取り頂いている
まあ、だいたい2週間経っても何も出ないやつが大半よ 
