「単体テストを手動で行いエビデンス取る」の破壊力 (709ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
228(1): 2020/09/26(土)12:20 ID:gRR2jm5z(1/16)調 AAS
単体テストはプログラマの自己満足だから無駄
っていう話がたまに出るけど、あれは一体何故なんだ
239(2): 2020/09/26(土)17:34 ID:gRR2jm5z(2/16)調 AAS
テストのスペシャリスト(エクセルスクショパシャパシャ)
実際、テスト計画からテストの自動化含めて全部やれる人って
ほとんどいない気がするか……
というよりテスト自動化すらまだ全然進んでない印象
253(3): 2020/09/26(土)17:59 ID:gRR2jm5z(3/16)調 AAS
>>243
>日本の仕事の生産性が低いのも細かいところで頑張って全体の品質から目を背けているからだ
>開発者が力を注ぐべきはプロダクトでありユーザの満足度だ
なんでアジャイル開発やTDDに発展していったかっていう経緯が全然分かってないやん
単体テスト無しで各コードが密結合されたプログラムの場合、変更のコストが膨大になる(作業工数の膨大）
で、プログラムっていうのは常に変化するものだ
不具合対応だけでなく、それこそユーザー要望によってコードはどんどん追加される
で、そのユーザーを満足さえるためにコードを変更するって事は仕様追加だけでなくて、既存仕様の担保も同時に必要になるんだよ
密結合されたコードは修正時の影響範囲が大きく、容易に変更する事が出来ない
何より変更後の既存仕様の担保っていう点で言えば、全てを保証するためには膨大なテストが必要になる
単体テストを『ちゃんと』作ると、プログラムは自然と疎結合になっていく（なぜならそうしないとテスト自体が書けないので）
更に仕様変更後も単体テストを動かす事で、少なくとも単体テストを実装している個所については
変更前後の動きを担保する事が出来る
もし抜けがあれば追加すれば良い、そうすれば次からはそこは抜け落ちない
つまり最初の工数こそかかるが、リリース後の保守/仕様変更に強いプログラムが出来上がる
これは長期的に見ればユーザーにも開発者にとっても大きな利点
お前はリリースした後の長期的な観点が抜け落ちてるからこそ、単体テストを軽視してるんだろ
ウォーターフォール式の開発で技術者寄せ集めてでプロジェクト終わったさー解散、ってやってるような奴だなとしか思えん
……というか調べたけど、テスラのロケットがシミュレーション止めたっていう話自体全然出てこないんだが……
255(1): 2020/09/26(土)18:03 ID:gRR2jm5z(4/16)調 AAS
というかユーザーは単体テストを見ない、だから単体テストは不要
っていうのは恐ろしいほどの暴論だぞ
ユーザーが必要としている領域と、開発側で必要としている領域は一致しない部分が出てくるんだから
全く理由になって無いぞ
257(1): 2020/09/26(土)18:56 ID:gRR2jm5z(5/16)調 AAS
>>256
じゃあ単体テスト不要の根拠になるソース出して？
>>154辺りの本が古いのであれば、当然当たらしいやつがあるんだよな？
ソースが無けりゃただの妄言だぞ
272: 2020/09/26(土)19:29 ID:gRR2jm5z(6/16)調 AAS
>>259
はい、ソース無し
というか単体テストすらまともに実装出来ない会社の間違いじゃないの？
274: 2020/09/26(土)19:47 ID:gRR2jm5z(7/16)調 AAS
マジで無能な働き者感半端なさ過ぎて洒落にならんな>ID:IgGP+BQU
あんまり煽るのは趣味じゃないが、流石にここまで酷いと思わんかった
>いまは結合テスト、総合テストを自動化して品質を高めるのが主流
本当に聞きかじりばっかだなお前
結合テスト/総合テストの自動化は開発の最終盤(UI含めてほぼ構成が固まった段階)に辺りからやるもんだぞ
さらに大前提として結合/総合時に自動化に耐えうるレベルでバグを潰しておく必要がある
つまり、単体テストで予めて一通りの品質が担保出来てなきゃ、自動化なんざ夢のまた夢だぞ
276(1): 2020/09/26(土)19:56 ID:gRR2jm5z(8/16)調 AAS
更に言うと、実行時間って言う面においては自動化を含めても
単体テスト>>結合テスト>>>>>総合テストっていう絶対に崩せない不等式がある
（総合テストはseleniu辺りを使ったものを自動化を想定してる）
単体テストはフィードバック速度が段違いに早いんだよ、だからアジャイル開発やTDDにおいても重要なファクターとなる
あとずーーーーーーと引っかかってたんだけどさ
単体テスト、結合テスト、総合テストは仕様通りに動くかどうかであって、ユーザー満足度とは何も関係無いぞ
仕様通る作成できている＝ユーザーも大満足する、にならないからウォーターフォールだとダメって風潮になってるんやん
（ユーザーの声が最後の最後にしか出てこないから、フィードバックを反映するのが困難なため）
ユーザーが満足するか、使いやすいかっていう判断をするのはユーザービリティテストっていう
評価観点が全く異なるテストを実施しないといかんのだぞ
流石に二日待っても『ユーザービリティテスト』って言葉が一回も出てこないから本気で心配してるんだぞこっちは
282(1): 2020/09/26(土)20:34 ID:gRR2jm5z(9/16)調 AAS
>>277
け、結合テストにユーザーを巻き込むwwwwwwwwww
ちょっと想像の斜め上どころの解答じゃなかったな
アジャイル開発でもそんなクレイジーな事せんわ
なんで結合テストしてない代物をユーザーと一緒にテストするなんて言うトチ狂った発想が出てくるんだよ
お前の開発環境クレイジーすぎるだろ……
297: 2020/09/26(土)20:55 ID:gRR2jm5z(10/16)調 AAS
>>283
>総合テスト > 結合テスト >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 単体テスト
はーまたソース無し
IPA辺りの資料だけど、アジャイル開発の進め方見てみ？
https://www.ipa.go.jp/files/000065606.pdf
9ページにはTDDを基本にするって書いてあるやろ？
つまり単体テストを避けて通れないの
あと先進的な設計・検証技術の適用事例報告書 2015 年度版の資料
https://www.ipa.go.jp/files/000049403.pdf
ここに単体テストの有用性を検証した結果出てるぞ、15ページな
それっぽい言葉で誤魔化してるつもりかもしれんが
何ども言うがソースが無いなら一切妄言と変わらんからな
303(1): 2020/09/26(土)22:42 ID:gRR2jm5z(11/16)調 AAS
>>299
>結局、単体テストのチェック項目は言うほど明確にならないってことだな
>浮動小数点の変数1つとっても厳密にやると恐ろしく時間がかかる
一回仕様決めてテスト書いたら
後はもう1関数辺り数秒にも満たない実行時間しか無いぞ……
つか浮動小数点のテストなんてそこれそユニットテストで良くやるやつやん
307(2): 2020/09/26(土)22:57 ID:gRR2jm5z(12/16)調 AAS
>>304
>・自動化Scriptの作成コストはでかい
それは正しいが、テスト自動化の作成/修正コストは
総合>>結合>>単体テストの関係になる
(必要な構成、モジュールが総合テストに近づくほど増えて影響範囲がどうしても増えるので）
>・単体テストよりもうちょっと上の階層のテストの自動化の方がよくないか？
総合/結合テストの自動化はバグを発見するのが目的ではなく
既存機能が壊れてないを確認するために使うんだぞ？
勘違いしてる人が要るかもしれんが、総合/結合テストでバグが頻発すると
テストが失敗した原因の調査〜修正の作業に無視できない工数がかかるから、
作成コストが少ない単体テストが整備出来てなきゃ宝の持ち腐れだぞ
>・そんなに何度も単体テストしないし
それは単純にサボってるだけ
継続的デリバリーとか継続的インテグレーションっていうスタンスで立つ場合
CIツール、例えばJenkins辺りで構築する場合
ソースをコミットしたタイミングで、コード解析、自動ユニットテスト、ビルドまで一連でやるようにする
だから一番動かすのはむしろ単体テストになる
https://www.techmatrix.co.jp/product/cisolution/service/index.html
https://tracpath.com/works/devops/continuous-integration/
>・かけたコストに対するリターンが小さそう？
んな事ない
上記の例も合わせてリターンは大きい
311(1): 2020/09/26(土)23:17 ID:gRR2jm5z(13/16)調 AAS
>>309
>作るのは簡単やろ
>だってUWSCで画面のボタンをポチって押すだけやろ
それは考えが甘すぎだわwwwwwwwwww
それだと操作しかしてないやん
UI周りの自動テストを実装する場合
・テストシナリオ(どういう操作をするのか）
・テストの判定基準
(想定通りの画面に遷移しているのか、表示されるメッセージが正しいか、データ登録が絡むならその結果も正しいのかなど）
・テスト結果の判別方法
(これはテストシナリオによって変わってくる、登録データをそのまま引っ張り出すならDB接続して想定値との乖離が無いかチェックする
ものによっては画面キャプチャで画像差分を見るってやり方もあるけど個人的には好きじゃない）
最低でもこの辺を意識して作らんといかんから、
そんな画面ポチポチ終わりーでいかんぞ…・…
特にUIの自動化は変更に弱い認識だから、本当に最後の最後で実装しないと地獄を見るし
314(2): 2020/09/26(土)23:25 ID:gRR2jm5z(14/16)調 AAS
>>312
単体テストでバグの発見数は正直重要じゃないな
というかそんなん集計とるか？
普通は単体テストが成功してからコミットするし、テストコード無しでコミットしようとしたらプログラマー〆るだろ
……というか仕様変更の度に関数が消滅と生成が起きるって
それはどっちかと言うとプロジェクトの問題では……？
317: 2020/09/26(土)23:39 ID:gRR2jm5z(15/16)調 AAS
>>306
そこは仕様によるし、あと責務の分割とかそういう発想でプログラムを組めばいい
超簡単な例として、電卓を上げるぞ
win10の電卓を叩くと
10/3 = 3.3333333333333333333333333333333
20/3 = 6.6666666666666666666666666666667
っていう感じで小数点31桁で出てくる
この結果から以下の仕様が読み取れる
・計算した結果が無限小数の場合、小数点は31桁まで表示する
・小数点31桁目は四捨五入して表示する
っていう仕様が予測できる
と言う事は、最低限の実装方針としては以下のようにすると、楽に単体テストが実装できる
・計算ロジック側は小数点31桁よりも大きい桁数でユニットテストは判定すれば良い、単体テストは可能だし、変更も簡単にチェックできる
・画面表示をする際に小数点31桁として出力するように四捨五入するメソッドを実装してかませればいい、このメソッドも単体テストが可能になる
ようは必ずしもすべての計算結果の小数点桁を指定する必要は無い、基本的には余裕のある実装にしておけば早々壊れない
318: 2020/09/26(土)23:50 ID:gRR2jm5z(16/16)調 AAS
>>315
それはテストツールによるとしか言えん
ちゃんとしたGUIテストツール使って、シナリオも確認してるのであれば
もちろんばログレベルの確認で良い
ただUWSCって名前が出たからついな
あれは自動操作用の目的だし、そもそも今開発止まってるから使うべきツールではない
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.034s