「単体テストを手動で行いエビデンス取る」の破壊力 YouTube動画>1本

単体テストは自動化するものだと思っていたから
一瞬何を言っているのかわからなかった

自動化＝手抜き

SIだぁ

手動＝努力・根性・体育会系・無能

たぶん、手動、自動化以前に単体テストができない人がいる気がする。

自動化って

メソッドsumAtoFの場合
引数A,B,C,D,E,Fの
処理S=A+B+C+D+E+F
戻り値S
のチェックって

int S=sumAtoF(A,B,C,D,E,F);
int chkS=A+B+C+D+E+F;
if(S!=chkS)
{
エラー
}

みたいになるの？
無駄じゃね？

>>5
指定されたテストケースを実行できない人はそういないだろうが
過不足ないテストケースを作り出すのはむしろできる人のほうが少ない
自動化を阻む一番の要因

>>6
1+2+3+4+5+6 の結果が 21 になってることを確かめるのがテストだろ
なんでテストで変数使うんだよｗ

>>7
それな。
4,000行近くの神クラスがあらゆるクラスと相互で強力な依存関係を持っていて、さぁ！単体テストやろう！
って言われても...単体って何だよ(哲学)

こんな感じになる。
いやもう俺の会社やだ。泣きたいわ。

>>8
どうやって21って出すん？

>>8
お前は仕様を先に考えないのか？
先にどうなるか答えは決まってるだろ

>>10へのレス

>>8
エクセルとかで予め計算しておいた値と比較するんだろ？
俺とやってること変わんなくね？

別で書いた計算式と本処理を比較するって点は一緒じゃん
それがエクセルでも処理言語でもやってることに違いなくね？

>>13
テストは、あらかじめわかっている答えと比較することなんですが？

あらかじめわかってるはずの答えを計算するなという話をしてる
その計算ロジックにバグがあったら、テスト（比較）で失敗したとしても
正しい値がなにかわからんだろ

>>15
だからどうやって21出すんだよって聞いてんじゃん
何言ってるのかわからないの？

>>16
自分で仕様を考えたこと無いのか？

1,2,3,4,5,6を与えたら21になる関数を作るんだろ
21をだすなら電卓でもなんでも使えよ

電卓が不安なら色んな方法を使って21が正しいと
確信もてるまで努力しろよ

そして21と比較するだろうが、21と比較する場面で
計算式を使ったら今度はその計算式が正しいかを
努力するしかなくなるだろうーが
それこそ意味がない

>>17
だからエクセルだか、電卓だか、別で計算した値と比較するだけで
どっちが正しいかなんてわかんねんだろお前ｗ

>>18
どっちが正しいかわからないから
計算式を書くなと言ってる

両方が同じ計算式だったら間違っていてもわからんだろ
片方が固定値であれば、こちらが正しい値であると考えてることがわかる

>>19
大して違いないってｗ
だったらログでも出して変数にしときなよ

>>20
ログ出してどうするんだ？
何が正しいかどうかをどうやって確かめるんだｗ

テストはロジック（関数）と固定値を比較することでやるという
基本的なことも知らないやつが居るとはなｗ

>>21
固定値が欲しいんだろ？
だからログでも出せばいいじゃんってこと

結局さ
やってることは1つの仕様に対して2つ処理書いてその値を比べてるだけ
別にテストコードに書いた値や処理のが正しい根拠もないし
本処理のが不出来である根拠もないでしょ

自動でやっても、テストコードとエビデンスのレビューをしろ、という
キチガイもいる

俺、この結論はどこまで行っても出ないと思うぜ
どっちが正しいかなんて誰にもわからん

>>23
お前はログに21と出力されているのを見て
これがどうやって正しい答えだって判断するんだ？
正しい答えが21ってわからないって言ったのはお前だろｗ

>>23
> やってることは1つの仕様に対して2つ処理書いてその値を比べてるだけ

それはお前がやってる無意味なことですよね？ｗ

そんな無意味なことはしないで、
1つの処理と1つの正しい答えを比べろって
俺は言った

テストと言いつつできるのは計算過程と処理結果を残すだけだと思ってるよ俺は
長年考えた結果
正しい値なんてのは実は物理的に誰も知りえないということを理解した

なのでテストで重視するのは俺は組んだコードのエビデンスの方
どんな処理書いてどんなログ出したか
自動テストは結局同じやつが作ってる以上同じ不具合入ってるだろうなって思ってるｗ

> テストと言いつつできるのは計算過程と処理結果を残すだけだと思ってるよ俺は

処理結果を残すだけというのは
間違った処理結果を残していてもいいって話ですか？ｗ

そうですね。お前はログ取るまでで
そのログを見るのは他の人ですもんね（笑）


こいつに、盗まれないように見ててって言ったら
盗まれました。ちゃんと見てました。って言いそうｗ

>>29
うん
だってさっきの21みたいにどこまで突き詰めたって
同じ仕様に対して別で2つ処理書いて比較してるだけだもの
んでこれを同じやつがやってる以上こんなところに金なんかかけるだけ無駄

>>30
論点がずれてるね。

お前はログを見て21であることを知って
あとからこの21は正しいのだろうか？と考えて判断すると言ってる。
どうやって21が正しいか判断するの？ｗ

俺は、最初に21が正しいと確信を持ってコードに書いてると言ってる。
だからお前がやってるログを取るだとかログを見るだとかいう無駄な作業がいらない

世の中にはテストケース1個作ることすらできない人もいるんだな
これは驚いた

>>31
確信ってｗ
無理なこと言うなよｗ

お前が本処理に書いたA+B+C+D+E+Fも
21を出すために書いたA+B+C+D+E+Fも
どっちも胡散臭ぇんだよｗ

こんな簡単なことがわからねーのかよ

ある関数を作ったその関数は
1, 2, 3 という引数を与えると3421という値がログに出力された

「これが書いたコードにバグなんてあるはずがない。3421は正しい計算結果だ。」

そういってログを取れば十分とつぶやいた

>>33
俺はそんなコード書いてないが？

こんな簡単なことがわからねーのかよｗ
IDも確認できねーのかよｗ

>>35
え？じゃあどうやって21出したん？

>>7
んなプログラマーってどうやって仕事をしてんだろう？

>>36
あのな、ソフトウェアの開発っていうのは
○○を入れたら○○になる関数が欲しい！
という考えの連鎖で作っていくんだよ

お前は誰かから課題を与えられるんだろうけどな
自分で考えて作るってことしたことないでしょ

作って終わりのシステムだったら手動でも問題ないと思う
Sierのユーザはテストのエビデンスを欲しがる人が多いから
エビデンスは納品物として残さないといけない

開発者よりもユーザ側の事情が大きいのじゃないかな

客「正しく動いているというエビデンスが欲しい」
SI「正しく動いてるかどうかなんてどうやって証明したらいいかしらん
テストやったというスクショ用意すりゃいいんじゃないか？」

これ

そうそう、結局こういう入力（ユーザによる操作や設定ファイルも含む）に対してこう動くようにしましたよ
としか言えない
だからエビデンスが重要だって言ってんじゃん
21が正解かどうかは誰にもわからないんだよ

もっと複雑な計算で客も式は知ってるけど
実際に計算した値はわからんようなのだったらどうやって出すよ？

PG「大丈夫、エクセルで数式でこのように出した値と一致しています!」
客「は？なんでそれが正しいの？」
PG「え？」

みたいになるやつはここの理解が足りない
どこまで突き詰めても究極的にはわからない
わからないものを説明しなければならない

> 21が正解かどうかは誰にもわからないんだよ
じゃあログ出す意味ないじゃんｗ
どうせ文字化け出力してても正解かどうかわからないだろ

> もっと複雑な計算で客も式は知ってるけど
> 実際に計算した値はわからんようなのだったらどうやって出すよ？

計算式は神が作り出したものとか、いきなり湧いて出てきたって思ってそうｗ
高校レベルの数学はそうだね。計算式は覚えるもの

だけどな、本当は計算式っていうのは、ある値を出したいと思って
「計算式を作る」ものなんだよ。作るのは計算式。それがコード

ゲームの当たり判定でも、あれとこれがぶつかったのは
どう計算すれば導き出されるんだ？って悩んで
ぶつかったという答えを出す計算式を作り出すものなんだが

本を読んで計算式をみて、ぶつかったかどうか？
この計算式を使えばぶつかったという答えが出るんだよ
みたいに思ってるんだろう。

自分でアルゴリズムを考えたことがないから
計算式ググって、そのとおり計算して
なるほど、これが計算した答えか。
答えなんて計算しないとわからんな。と言ってる
計算式を作り出したことがない

フフフ、雑魚の遠吠えが心地いいなｗ

内部にジェネレータとかIOとかを持ってて、冪等じゃない関数のテストってどうやったらいいの？
そういうのは単体テストの対象外？

>>45
１つぐらい何か言い返せよｗ
お前がやってるそれが遠吠えじゃねーかｗ

>>46
冪等性がなんで出てくるのか知らんが
与えられたデータ（引数だけじゃなくてすべての状態）が
同じであればその結果も同じになる

テストというのは、固定のデータを使って固定の結果と比較するもの
固定のデータが用意するのが難しいのであれば
その部分にスタブ（モック）を利用する

十分、単体テストの対象内
というか単体テストができないなら、その他のテストもできないだろ

>>47
だからなんの意味もねーってそれ
お前がエクセルで計算した値だろｗ

>>41
>そうそう、結局こういう入力（ユーザによる操作や設定ファイルも含む）に対してこう動くようにしましたよ
>としか言えない

考え方が間違ってる
入力に対する出力が要求仕様通りになることをこういうテストケースで確認しましたよと言えればいい
21が正解かどうかは要求仕様による

テストケースを作る能力の有無の前に
要件定義がまともにできてることが必要
できてなければデスマーチ確定

>>49
だからそう言ってるじゃん
>>41にそう書いてあるだろ

>>48
> お前がエクセルで計算した値だろｗ
何で計算するとかどうでもいい話だろ

何をする関数を作りたいのか？
作りたい関数は「何を入力とし、何を出力とするのか」

その仕様を決めてから関数を実装する。そして正しく実装されてるかテストする

お前は仕様を決めずに、関数を実装して
その関数が出力する答えが正しい！バグなんてない！って言ってんのか？

繰り返すぞ
仕様を決めてないのに関数を実装してんのか？

関数なんかフィーリングでつくるだろうふつう
関数の設計？関数仕様書みたいのをいちいち書かせるタイプのアフォなんか？

>>51
ホントだ
どうでもいいなｗ
だから>>6でもいいんだよな？

>>50
何を書いたつもりなの？

>>53
> だから>>6でもいいんだよな？

>>6には固定値が書かれてないから駄目だって言ってんだろ
理解できますか？

あ、そう。理解できない。
↓こうしろって言ってるだけなのに、理解できないのか？終わってるな

int S=sumAtoF(1,2,3,4,5,6);
int chkS=21;
if(S!=chkS)
{
エラー
}

>>55
え？じゃあどうやって21って出したの？
こんなの固定値のわけないじゃん

> え？じゃあどうやって21って出したの？

最初に関数を実装するんじゃやなくて
仕様を定義しましょうと言ってる


お前は仕様を決めずにいきなり関数書いて、その関数の実行結果を出力して
俺がコードにバグを入れるなんてありえない。だから21が正しい！と言ってるだけ。
テストを全くしてない

>>57
それで？
どうやって21を出したの？
ここが品質のすべてを担保してるのにどうでもいいわけないだろアホか

>>58
> どうやって21を出したの？

「例：1,2,3,4,5,6を引数に渡したら21を返す関数が欲しい」
という要件

最初は関数（コード）は存在しない
最初に関数（コード）を実装してはいけない
実装した関数（コード）で出してはいけない
実装する前に決める話


どうやって21を出したの？
それはその関数が欲しい人に聞け

>>59
ええ？A+B+C+D+E+Fなんだけど？

>>60
それは実装

最初に実装を書くなと何度もいわせるな

>>61
今回は客がそう言ったのな

>>62
客はお前より頭がいいなｗ

なんか荒れてんな。

単体テストって固定された仕様に対して実装者次第で変化するロジックをテストするものだろ。

例題があまりにも単純コードだからロジックと実装が一致するなんて現象が起きるのであって、考え方はテスト仕様を満たしているかどうかが重要。

だと思うんだぜ。

>>64

> 例題があまりにも単純コードだからロジックと実装が一致するなんて現象が起きるのであって、

ロジック(実装内容)とテストコードの間違い

>>65
そこじゃないよ。
あのアホは「足し算をすることで21になるかどうかわからない」から
コードを書いてそのコードの出力ログで21とでたからOKOK。
21になるかどうかわからないけどログにそう出てるからOKOKって言ってるわけだから

仕様からロジックを作り出すことができなくて、
ロジックを与えられて、そのロジックをコードで書いてるだけの人間なんでしょう
コーダーってやつ

>>66
ほう、それじゃ君はどうやって21を出すんだい？
偉そうなこと言ってるんだから誰もが納得できる解答をもっているんだよね？

>>68
納得できてないの、お前だけみたいだぞ。
キョロキョロ見回してみなw

ちなみに俺は答えを持っているぜ
お前ら雑魚といっしょにするな

お前らは正しいかどうかわからない自動テスト（笑）をずっと動かしていればいいよ

なんだかなぁ...。
sumAtoFって名前からして引数のAからFを足したやつを吐き出すのが仕様なんだろ？

じゃあ、その仕様に合ったテストコードを書けばいいじゃん。

って話なのだが...まぁ、それ以前に、だ。
うん？単体テストをする上でテスト対象のメソッドの仕様がわかりませんってやばくね？

>>71
テストコードを書くには、関数の計算結果がわかっていなければいけない
だが関数を実装しなければ、計算結果は求められない
関数を実装するまで、計算結果はわからない

などと言ってるやつだからなぁ
どうしようもないよｗ

>>70
ほう、それじゃ君はどうやってログに21がでてて安心するんだい？

アホの相手飽きたから質問ｗ

BDDとTDDとATDD について

調べてみるとBDDは受け入れテストのような説明がされていて
これってATDD（Acceptance Test Driven Development）のことだと思うだけど
・・・正確に言えば受け入れテスト駆動開発と言うべきか・・・はいいとして、

でもrspecってBDDと名乗っているけど、どうてみてATDDではないように思えるんだよな
開発者のためのテストが主だし。

cucumberは明らかに受け入れテストだと思う。rspecにturnipを組み合わせても
受け入れテストになると思う。でも素のrspecはBDD（ATDD）ではなくTDDだと思う
さらにググるとBDDを取り入れたTDDと書いてあるのも見つけた

rspecってBDDを名乗ってるけど正確な言い方ではないってことなのか？
さらにrspecの言うBDDと同じ意味で使ってるテストフレームワークが多い気がするけど
最初から受け入れテストとして作られたものは本来（？）の意味こそがBDDだみたいな感じで
BDDという用語を使ってる気がする

という認識はあってる？

和田さんのいう「誰のためのテストか」っていうのが
これらの用語の使い分けとして一番しっくり来るんだよな
ただこういう観点で使い分けられてないという事実があるわけで困る

https://www.slideshare.net/nowsprinting/bdd-33testing
Scenario BDDとかSpec BDDとかいう用語が出てきたｗ

BDD は、rspec, jest みたいに、describe, it を使うもの

>>77
俺もそう思っていたんだが、どうも違うんだよな
人それぞれで言ってる意味が微妙に異なってる

たぶん、この意見は正解。２つの意味がある。

https://ukstudio.jp/posts/2011/07/02/bdd/
> BDDにはふたつの種類がある
> 1. TDDの言い換えのBDD(開発寄り)
> 2. ATDD(受け入れテスト)でのBDD(ユーザ寄り)

2つの意味があるのは、まあよくある話なんだけど
1.界隈では何の説明もなくBDDはTDDの言い換えとして使っており
2.界隈では何の説明もなくBDDはATDD前提で語っており

各解説を見ると、この２つの種類がまるでなかったような書き方がされてる
それぞれの専門家は、どちらかの用語として使っていて
こういうそれほど有名でない人だけが違いに気づいているという感じがする
あ、和田さんは有名だけどねｗ

BDDはTDDの言い換えとして広まっちゃってるけど
BDDのオリジナルは多分受け入れテストの方だと思う

だからrspecのBDDは本来のBDDではない！と専門家が批判記事でも
出していればまだ良かったんだけど、それがないから困惑してる

rspecがBDDを名乗っており誰も批判してないからrspecはBDDである。
それを真似たjestなどもBDDである。共通する特徴はdescribe, itである。
これが開発者の間で広まってる認識・・・だと思うんだけど受け入れテスト業界では
rspecのBDDを否定せずに、それでいてBDDはATDDであるという前提で語るから困る

ちなみにATDDっていうのはcucumberみたいなものね

RSpec と言えば、ソニックガーデンの伊藤淳一。
Read Everyday Rails も翻訳してる

「伊藤淳一 rspec」で検索！

色々な記事を書いてる

> RSpec と言えば、ソニックガーデンの伊藤淳一。
その人ぐらいしかいないから名前が知られてるだけで
特別参考になることは言ってないかな
大幅に間違ってないってだけで、大多数の人と同じレベル

TDDやBDDじゃなくて、 xBehaveとxSpecで検索すべきだった
おそらくrspecはxSpec系と呼ぶのが適切なのだろう

伊藤淳一は、YouTube の動画もある

他には、Serverspec の作者、宮下剛輔もいる

> 伊藤淳一は、YouTube の動画もある
あれやめて欲しい
せめて文字に起こせと

Ruby のYouTube 動画で、Dean DeHart というマニアックな香具師がいる

テスト書き始めるとオブジェクト指向おじさんから関数型おじさんになってしまう
Javaでも全部staticメソッド

ユニットテスト全く書いたことないのか？っていうレスが最初の方で飛び交っててやべーな
それどころかテストケースの洗い出しとかその辺の事全く知らなそう

>>86
テスターに任せるだけだから気にしなくていい

なんでもかんでも自分でやろうとするな
組織は集団の力を使えるから強いんだ
テストはテストの専門家に任せるべきだ

単体テストを頑張っても品質はあがらない
結合テスト、総合テストを頑張るべきだ

効率化しすぎたら仕事が無くなるよ

>>89
>単体テストを頑張っても品質はあがらない
>結合テスト、総合テストを頑張るべきだ
単体テストの重要性を知らんのか
レガシーコード三部作を買って読んで来い

>>91
例えばチェックする値の理論値が12.375だったとするじゃん？
でも計算結果は
12.37499999999998
だったんよ
お前、これどうすんの？

>>92
精度付きで比較する
テストフレームワークがそういう機能を用意してる

>>93
えー一個一個設定すんのー？

>>89
> 結合テスト、総合テストを頑張るべきだ

手戻りが大きくて時間がかかりすぎる

>>94
お前ならどうするのか言ってみ
もしかしてログにでていてそれっぽい値だからOKって
目を凝らして何百個も判断するのか？ｗ

>>96
いや、得に仕様は出てないんでテキトーに判定して欲しいんですが

>>88
テストの専門家というのは、テスト技術の専門家であって
テスト作業の専門家なんていねーぞｗ

それは単なるテスター。テスト作業してるだけで専門家じゃない
ひどい場合は仕様も何も知らないやつが手動でテストしてしてたりするからな
テストの効率化？人増やして人海戦術でやることだなみたいに思ってるやつ

>>97
テキトーに判定って 12.37499 という間違った
計算結果になってる場合でも場合OKにするってこと？

>>94
一つ一つ指定しない方法もあるよ
そういうのもテストフレームワークに用意されてる

>>99
概ね当たり感出てるじゃないですか？

>>101
だから、間違った計算結果でも
概ね当たり感出てるからOKにするってことですよね？
って聞いてるんですが

>>100
どんな設定よ？
0.99999999999998みたいなのを概ね1.0お判定してくれそう？

ビッグバンテストって今時はやらないの?

>>103
> 0.99999999999998みたいなのを概ね1.0お判定してくれそう？

0.99999999999998 を 概ね1.0と判定してほしいの？
0.9999999999998 だった場合は？
0.999999999998 だった場合は？
0.99999999998 だった場合は？
0.9999999998 だった場合は？
0.999999998 だった場合は？
0.99999998 だった場合は？
0.9999998 だった場合は？
0.999998 だった場合は？
0.99998 だった場合は？
0.9998 だった場合は？
0.998 だった場合は？
0.98 だった場合は？

>>105
一番下は最悪だなｗ

概ね当たり感わかんねーんだよな自動テスト作ってるやつバカだから

>>106
下から2番目は？
下から3番目は？
下から4番目は？
下から5番目は？
下から6番目は？
下から7番目は？
下から8番目は？
下から9番目は？
下から10番目は？
下から11番目は？
下から12番目は？

複数質問してるんだから全部答えてよｗ

>>97
>いや、得に仕様は出てないんでテキトーに判定して欲しいんですが
そういう曖昧な仕様だからバグに繋がるんだろうがwwwwwwwwwww
特に浮動小数点の計算なんてよくバグに繋がるから仕様はっきり決めてテストしなきゃダメだろ
桁数どうするかとかね

あと数値系のテストってそこまでパターン無いぞ
・一般的な正常値
・境界値
・最大値/最小値
・異常系(メソッドの仕様によって変わる、nullとか空白とか）

テストフレームワークには網羅的なテストデータの投入と判定を一気にやってくれるし
それぞれでテストコードを書く必要はないぜ

>>107
> 概ね当たり感わかんねーんだよな自動テスト作ってるやつバカだから

お前にその概ね当たり感を聞いてるのに、その質問に答えられないお前はバカってことになるよ

消費税計算で1円ずれてても概ねおっけー♪
トランザクションが1万件あっても1万円しかずれなーい
とかいいそうなんだよなｗ

やっぱり自動テストは駄目だな

>>92
浮動小数点の計算するなら許容誤差ぐらいは理解してからやれよ…

>>112
質問に答えられなかったという結末で良いね

>>110
というか「概ねオッケー」っていう考え方ってプログラミングだとめちゃくちゃ危険だからな
α版とか仕様の仮決め段階だったらまだいいけど、正式リリースの時までその状態にしておくと
絶対にそこ起因のバグか仕様か分からん動きが発生してトラブルになって揉める

当時の議事録とか仕様書の調査に入って悲惨な惨状になるのが良く見える

>>113
いや仕様が出てれば有効桁数いくつか指定すればいいけど
計算式しか出てないやつは直前の複雑な計算に引っ張られてる感しかないんだよなぁ

>>116
python辺りのユニットテストフレームワークだと丸め桁まで指定できるから
それで満足する？
https://docs.python.org/ja/3/library/unittest.html#unittest.TestCase.assertAlmostEqual

>>116
引っ張られるとかイミフなこと言われても…

>>95
単体テスト用意してるから実装がグダグダになるんやで
実装に集中しろ

いや、突っ込んだ引数と理論値から有効桁数勝手に判断しろ
人間ならできる

>>119
>単体テスト用意してるから実装がグダグダになるんやで
>実装に集中しろ
そうやって場当たり的な実装になるから
クソみたいなコードが量産されるんだろうが……

単体テストに時間割く方が危険
IDEや静的解析があるから単体試験で見つかるようなコーディングミスは
ほとんどない、むしろバグの多くは仕様に対する認識不足によるものが多い
結合、総合テストを重視したが良い

>>121
んなこたーない、単体テストもコードの一部だからバグ増やすだけ

>>120

7Payもドコモ口座も単体テストはちゃんとできてただろｗ
総合テストを軽視した結果があれ

>>124
だって値2000個以上あるし

単体テストはプログラマの自己満、システムの品質をあげないどころか
結合、総合テストの時間を減らしてシステムの品質下げることになってる

まーた、仕様を理解しないままテストするとかほざく単体テストを理解してない馬鹿が湧いたのか。
いい加減にしろや。

>>126
そういう意味で大変って思ってるなら
テストデータ流すして結果が出た後、
その桁数からparseで指定する桁数を決めてから判定すりゃ良い

2000個どころじゃねーな
変数30個ぐらいのクラス200個以上あるもんな
一個一個有効桁数の設定なんかしてらんねーよ

単体テストは自己満、リファクタリングは時間の無駄

>>122
>単体テストに時間割く方が危険
>IDEや静的解析があるから単体試験で見つかるようなコーディングミスは
>ほとんどない、むしろバグの多くは仕様に対する認識不足によるものが多い
>結合、総合テストを重視したが良い

は……？
いやいやお前は単体テストをなんだと思ってるん？
そんなショボい事になんか使わんぞ
仕様を関数レベルにまで落としこんで、その振舞が正しいかを見るのに使うんだぞ
むしろ仕様認識不足がバグの原因っていうなら、それこそ単体テスト書かなきゃダメだぞ
特に仕様変更とかでコード修正入れたら回帰テストする必要があるから
単体テストが無いと修正前の担保とれんやん、やべーやつだなお前

たしかに単体テストすらできないゴミプログラマーがするリファクタリングは虚無だわな。
まともに設計できないだろうし。

時間がかかるのでメソッド単位の出力値のテストはなかったことにします

>>125
あれはテストの問題じゃなく仕様の問題
それも仕様のリスクは精査されてたが意思決定者がそのリスクを軽視しただけ
よくある話

単体テストとかTDDとか全く分からんなら
この動画が一番参考になるから見ておけ

;list=WL&index=4&ab_channel=TDDBC-Online

>>133
そもそもリファクタリングって単体テスト有りきじゃね？
コードが悲惨すぎて単体テストの実装すら困難って時には
リファクタリング→単体テスト→リファクタリング→再テストっていう流れになるけど
基本的には現行動作を保証するために単体テスト実装→リファクタリング→再テストが基本だし

>>132
単体ｗ 単体で仕様確認する暇あったら結合、総合で確認しろよｗ
単体で仕様確認できると思ってる方がやべーわｗｗｗｗ

テスラのロケット知ってるか？ 部品のテスト頑張ったらロケットが飛ぶと思ってそうだなお前

>>135
総合テストを重視してたらその仕様の問題もはっきりわかったってことだ
お前のように単体テスト頑張るやつが開発者だったんだろｗ よくある話だな

テスラではシミュレーションをなくして実地で何回もロケット打ち上げること
繰り返して洗練させていったんだよ

単体テストやるやつは所詮ホリエモンロケットなんだよｗｗｗｗｗ

単体テストとリファクタリングを重視していたのは15年前～8年前まで
日進月歩で進化するシステム開発の現在の常識は単体テストとリファクタリングを禁止する方向

>>136
俺の発言は皮肉で言っただけだから、あまり気にせんでくれ。

俺があげたのはまさに、コードが悲惨すぎて単体テストができない例。そういう人達の頭の中では単体テストって無意味なんだろうな(遠い目)
って皮肉だから深い意味はない。

TDDはプログラミング界のマナー講師だからなｗｗｗｗ
ありもしない偽の常識でっち上げて自分が日銭稼ぐのを目的にやってるだけだから

>>137
あのな？
単体テスト、結合テスト、総合テストもどれも重要なんだよ
で、単体テストで扱けるものは結合テスト、総合テストでもこけるんだよ
単体テストで拾えるレベルのものを何度も時間と手間かけて結合・総合テストやる方が気が狂ってるわ

>>140
>日進月歩で進化するシステム開発の現在の常識は単体テストとリファクタリングを禁止する方向
で、どこの奴が言ってるの？
常識って言うなら少なくとも本ぐらいは出てるよねー？
あ、ファクタリングと単体テストの重要性は大体この辺の本に載ってるぞ
・リーダブルコード
・リファクタリング 既存のコードを安全に改善する（第2版）
・ベタープログラマ
・テスト駆動開発
・レガシーコード改善ガイド
・レガシーソフトウェア改善ガイド
・レガシーコードからの脱却

>>142
お前が一番マナー講師臭がプンプンするぞw
しかも説明のしかたに説得力がないからかなり質の低い部類の講師だな

>>143
ほらねｗ その本全部15年前～8年前のものだよｗ

最新情報をキャッチアップできてない
いま単体テストが一番レガシー

>>130
2000個全部有効桁数違うのか？
まあありえねーとは言わんけど残念な仕様やねw

>>145
で、お前のとんでも理論が載ってるホン早く出せよw
ネットでもいいぞ

>>148
企業では普通に行われているよ
一般に漏れ出るのはだいたい10年後くらいじゃないかな

10年前の本読んでる時点で時代遅れだからｗｗｗｗｗ

>>144
自演？流石にこのスレにここまで頭のおかしい人が二人もいたらびびるのだが。
>>149
妄想乙

>>128
いや、突っ込んだ引数と理論値から有効桁数勝手に判断してテストすればいいじゃんｗ

C10K問題ってしってる？ あれも企業では当たり前の問題として知られていて
とっくに解決策もわかってたんだけど、それが世に出て一般に知られて本がでたのは10年後だった
技術の最先端は常に企業にある

>>145
・リーダブルコード：2012/6/23
・リファクタリング 既存のコードを安全に改善する（第2版）：2019/11/29（第1版：2014/7/25）
・ベタープログラマ：2017/12/15
・テスト駆動開発：2017/10/13
・レガシーコード改善ガイド：2009/7/13
・レガシーソフトウェア改善ガイド：2016/11/10
・レガシーコードからの脱却：2019/9/19

流石にちょっとぐらいググろうぜ？
古い本から新しい本までバランスよく混ぜて
単体テストとリファクタリングっていう方針は10年近く前から廃れずに続いているって察してくれると思ったんだけどなー

>>130
> 変数30個ぐらいのクラス200個以上あるもんな
> 一個一個有効桁数の設定なんかしてらんねーよ

有効桁数の設定の意味がわからん。
例として一つだけやってみて

いま10年前の本読んで実践してる人は最先端から20年遅れてるｗｗｗ

>>153
> 技術の最先端は常に企業にある
C10K問題を解決した企業の名前言ってみ

>>154
初版の発売日調べてみ、著者が金稼ぎのために版増やしてるだけだから
お前のような情弱を釣ってるだけｗｗｗｗ

>>158
> 初版の発売日調べてみ、著者が金稼ぎのために版増やしてるだけだから

金稼げるってことは売れてるってことだよな？
お前、何がいいたいの？

>>158
全部初版の日付だよwwwwwwwww
お前だけ時間おかしくね？

>>157
NTT NEC 日立 富士通 IBM HP Oracle Microsoft 三井住友 GE

>>161
全部単体テストを行ってる会社か
最先端は単体テストだな

訂正

全部単体テスト"自動化"を行ってる会社か

>>160
お前が見てるのは再販の日付だろバーカ
これだから情弱は・・・

お前のような情弱が買うから著者は版を増やすんですねー

むしろこの流れで初版の日付書いて無かったらただのアホだぞ

>>153
話題そらすの大好きだね。ＯＯスレ荒してた奴だらお前

>>162
10年前までな

>>166
お前誰だら

>>167
10年前にやめたという情報がないなら、お前は嘘つきってことだよ
嘘つきだね

10年前で時が止まった人間がIT業界でお仕事してるってうけるんですけどーｗｗｗ

単体テストの基本
https://docs.microsoft.com/ja-jp/visualstudio/test/unit-test-basics?view=vs-2019

vs-2019、この記事は10年前に書かれたとでも言うのだろうか？ｗ

>>170
類は友を呼ぶだけ。つまりお前とお前の周りは無能ってことだよ。

大企業は単体テストを続けてるからね

テスト自動化の基本的な考え方とNTTにおける研究開発の紹介
丹野 治門 （NTT研究所） 2019年3月26日(火)


http://www.jaspic.org/wordpress/wp-content/uploads/JASPIC_SPI-TwilightForum_20190326.pdf

>>164
へーアマゾンの日付が間違ってるのかーそうか知らんかったなー
あ、オライリー本についてはここの発売日から取って来たからな
https://www.oreilly.co.jp/index.shtml

むしろ再販の日付の方が探すの面倒だろwwwwww
実際の本見ないと第何版の何時印刷か書いて無いし
その後ゴリ押しは無理だろ

その場のノリで嘘をつくから
こうやって証拠出されて言い返せなくなるんやで

素直に逃げてれば、負けを感じることもなかったのにな（笑）

>>168

試しに聞くけど
1.カプセル化についてどう思う？
2.オブジェクト指向についてどう思う？
3.staticおじさん大好き？

>>147
そんなの把握できてるわけ無いだろ
でも設定しないとチェックはできん

>>177
だから1個でいいか設定とやらの例を言ってみろって

>>149
ごめんね、俺５年前までHの子会社でHの仕事してたんだけど、どこでその最先端のとんでも理論を普通にやってるって？
てか、企業って結構こういうものの対応遅いぞ
特に大企業は手順書とか規格とか山のように修正しないとできないし

>>178
わからん!（ガチで）

>>180
え？設定なんていらない。それっぽい値がでてればOK
1円ぐらいずれててもいいやろ
って言わないの？ｗ

>>181
いや、スタンスはそれ

>>182
つまり計算結果が間違っていてもOKってスタンスなんだね

>>183
わからないが正解だな
10000個近くの変数の1つ1つは無理ゲー

まさかバグでOKというスタンスだったとはｗ

>>184
つまり10000個近くの銀行口座があって
1つ1つ不正送金を調べるのは無理ゲーとｗ

>>185
だって有効桁数わかんねーもん

>>187
仕様がわからんとか下っ端の人間か？
自分で決める立場じゃないなら、上の人に仕様もらえなｗ

>>177
把握もできずにコーディング？
なんか勘違いしてると思うが計算式毎に有効桁数がここは６桁、ここは４桁とかってやるんじゃねーぞ
普通は最低限必要な有効桁数がちゃんと計算されてるかを確認するだけ
※ 計算式によっては例外あり

>>189
だからよ
ものによって
この値はだいたいこんなもんだろってあんじゃん

3.5とか5.5ならまあそれよ
でも
0.0000008596とか
0.00000052354
みたいなのが日常な変数もあんじゃん
でも出力値見ればな～んとなく

まあ、あってんじゃね？
ってわかるじゃん
それよ

>>190
今度は逃げずにレスするのか？ｗ

> 0.99999999999998みたいなのを概ね1.0お判定してくれそう？

0.99999999999998 を 概ね1.0と判定してほしいの？
0.9999999999998 だった場合は？
0.999999999998 だった場合は？
0.99999999998 だった場合は？
0.9999999998 だった場合は？
0.999999998 だった場合は？
0.99999998 だった場合は？
0.9999998 だった場合は？
0.999998 だった場合は？
0.99998 だった場合は？
0.9998 だった場合は？
0.998 だった場合は？
0.98 だった場合は？

>>191
自動テストはやっぱり駄目だな

>>192
なんでまた逃げたの？

>>193
だって有効桁数わかんねーもん

>>194
わからないなら上に聞けって、仕事できないやつだなｗ

>>195
数の暴力に屈してしまうのです!
数の暴力に屈してしまうのです!

こいつにテストさせたら、それっぽい値なので問題ないと思いましたって答えそうｗ

>>194
すまん、単体テストをどういう風に想像してる？
a：関数の返り値/実行結果のみを単体テストで確認する
b：実装されてる全ての変数(ローカル変数/グローバル変数）の値を全部チェックする

一般的に単体テストってaしかやらんけどもしかしてbをやろうとしてる…・…？
なんか変数が10000個っていうのを見ててふっと思ったから一応確認したい

>>198
過去ログ見る限り計算結果をログに出して
目視で数字みてそれっぽければOKらしいよｗ
これが単体テストだとさ

(ぶっちゃけ浮動小数点数のテスト仕様を深く考えたことがなくて焦ってる自分がいる)

>>190
> まあ、あってんじゃね？
> ってわかるじゃん
なるほど、ならいいんじゃね
俺には関係ないだろうしw

出力がよ
ほとんどDBにぶち込む値だから
メソッドの出力がほとんどチェック対象なんだよね
メソッド数でいうとクラっとするけど
変数の数なら10000ぐらい

補足

>>202が言ってるのは、その10000ぐらいのメソッドを
目視で確認するのは大変だから、もうそれっぽければOKでいいじゃん
という意味です。

さらに補足すると

10000ぐらいのメソッドを全部自動化でテストするの大変じゃん！
目視でいいよ目視で

という意味です。

DBに書き込む値を概ねで済まそうと思ってたのか……（驚愕)
バグ出た時の影響範囲がやべーぞ

一日一万個感謝のフィールドチェック

>>174
アマゾンの日付ｗｗｗｗ
お前そんないい加減なことやってんの？ 驚愕だわｗｗｗ
お前の単体テストもそんな感じなんだろ

アマゾンの日付ｗｗｗｗｗ
出版社に電話かけて原本の初版の発売日聞いてみろ
ほぼ全部20年前だから

未だに単体テストの本書いてる人はいるだろうが
お前のようなただの情弱だからｗｗｗｗ

アマゾンの日付ｗｗｗｗｗあかんわろてまうわｗｗｗｗｗ

>>176
試しに逆に聞くけど君はどう思ってるの？

オブジェクト指向逆にどう？

発狂したww

>>211
別に？
あって当然のノウハウであり、必須すぎてどうかと問われても困る。
もしも、そこから否定する馬鹿がこのスレにいたら流石に驚く。

まぁ、そのレベルなんじゃないかって疑われてんだよお前は。

>>208
1時間近く考えた結果がアマゾンの日付が間違ってるとかwwwwwww
いや、別に煽るのは構わんけど、原本20年前で戦うのは無茶だぞ？本当に

例えば最新のプログラミングノウハウ書かれた本、英語の原本でも良いから紹介してくれん？って言っても
自分で調べろ一転張り多分出す気無いと思ってるんだけどさ
そうなると自分の主張を補完するソースというか書籍を出せないけどそれは良いのか？

「自分の主張はネットにも書籍にも載ってないけど絶対に正しいです」って言うのは多分一番人を納得させるのが難しいけど良いのか？

>>152
今更だが、ごめん。このスレタイのせいで俺のツッコミが自動化の否定に捉えられたか。
そういう意図のツッコミじゃなかったんだ。
すまぬ。

>>214
沢尻エリカじゃんｗｗｗｗやるじゃんｗｗｗｗ

>>217
いい加減に俺の質問に答てくれ。
お前は別スレでも、いつも都合が悪くなると質問を質問で返したり、無関係な話に話題を逸したり、どうでもいいところで揚げ足を取って相手を批判するよな。

今度はそういうの無しで頼むわ。

>>218
わかった、質問を言ってくれ

176で質問してるんだがな。
質問の仕方を変えるか。
君さ、そもそも有意義な単体テストができるコードを書ける？神クラスとか作ってない？

>>208
> アマゾンの日付ｗｗｗｗｗ
> 出版社に電話かけて原本の初版の発売日聞いてみろ

Amazon（もともとは本屋）はISBNがついている本の情報は出版社から仕入れています。
一応メインであるはずの商品データを手入力してる訳がないやろｗ

クソみたいにピーキーなアサート入れるテストするくらいならそのままログ出力でもしろっていう
馬鹿コード書くやつはよく見るわな。

ピーキーなアサートの意味がよくわからんがアサートとログじゃ用途が違うからお前のアホ意見は却下で

そうやって揉めるなら手動+Excelでいいよねっ

よくないが

アサート書いて実行したらテスト完了、エラーがあれはエラーの出たテスト箇所を知らせるでいいじゃん。
なぜログの目視に拘る。

>>226
成功したところはやってないとかイチャモンつける馬鹿だから。
全ログ流しときゃいいのよ。
馬鹿と馬鹿に挟まれながら作業するってのは大変よ。

単体テストはプログラマの自己満足だから無駄
っていう話がたまに出るけど、あれは一体何故なんだ

>>228
使ってない奴がわめいてるだけでしょ
自己満足だろうが修正時の安心感を捨てるとかあり得ん

コーダーの安心感のためにどれだけの人件費がかかってると思ってるんだ
経営者目線で仕事しろ

自己満で仕事するな、テストはテストのスペシャリストにやらせろ
組織の足を引っ張ってることを自覚しろ、単体テストをいますぐやめなさい

うわぁ病的なの湧いてるなw

またycF3TYueかよ。いい加減、ROMってろ。

経営者目線がツボるわw

>>226
> アサート書いて実行したらテスト完了、エラーがあれはエラーの出たテスト箇所を知らせるでいいじゃん。
> なぜログの目視に拘る。

アサート書くためには関数の戻り値が必要
だけど関数の戻り値はわからない。
計算式が難しいから、実際に関数作って実行してみないと、計算結果はわからない

だから最初に関数を作る。
その計算結果がそれっぽければ、関数にバグはないとみなす。

関数にバグはないとみなしたからと言って、本当に関数にバグがないかどうかはわからない
つまり計算結果が正しいと証明する方法は存在しない。
だからログを目視してそれっぽいかどうか見るしかない

という理屈だそうな（笑）

>>235
その「それっぽい結果の判定」をテストコードとして記述すればいいのに。
そもそも、テスト仕様が不明確な時点で駄目な気がするが...そういう開発しかした事がないのかな。詳しくは本人に聞けってところか。

>>231
経営者目線で仕事をするのなら、単体テストくらいできるようになってくれ。
意味のある単体テストすらできない生産性の低い奴とか俺の会社にイラネ。

もしもテスターと詳細設計担当が別人で、単体テストができないくらいクラス間の依存強度高いクソコードを渡された側であれば許すが、クソコードを作った挙げ句、自分のクソコードを反省もせず、単体テストは無意味だとほざく奴はイラネ。

数千から数万台出荷される製品のソフトウェアや、一般公開されているライブラリに対して単体テストしてませんとか言ったら出荷や公開を止める。リスク高すぎだろ。
なんでたかが人件費のために単体テストをやめるんだよ。それすら回収できないの？
受託開発だったらそこは委託元と相談して決めることだし、自社開発だったら...ビジネスモデルが破綻してるな。

詳細設計そのものがクソでも他テストは通る恐れがある。
販売活動中に詳細設計がクソすぎて開発が止まる恐れのある製品とか怖くて売れない。

>>236
経営者目線で単体テストてｗｗｗｗｗ
ｗｗｗｗアホすぎわろすｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗひぃーひぃー腹が痛いーｗｗｗｗｗｗ

単体テスト頑張れば頑張るほど品質は下がるというのが現代のものづくりの常識なわけだが
10年前の本読んで仕事してる人とは仕事したくないなあｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

テストのスペシャリスト(エクセルスクショパシャパシャ)
実際、テスト計画からテストの自動化含めて全部やれる人って
ほとんどいない気がするか……

というよりテスト自動化すらまだ全然進んでない印象

自動化しなくても良い、総合テストに時間をかけたほうが製品の品質は高まる
テスラのロケットもそうやって飛んだんだよ

自動化という手法にこだわってコーダーの自己満で単体テストやってるのは
所詮ホリエモンロケット止まり

大事なのはユーザビリティでありプロダクト
細かい部品のチェックを頑張ってもどうにもならんぞ

>>240
ycF3TYueさんよ、マジで黙っててくれないか？
お前さっきから邪魔。昨日のように逃げて大人しくしてろ。

単体テスト頑張って会社の売上が上がった人は単体テストのコンサルタントやってるIT業界のマナー講師くらいだろ
やってることが自作自演なんだよ

日本の仕事の生産性が低いのも細かいところで頑張って全体の品質から目を背けているからだ
開発者が力を注ぐべきはプロダクトでありユーザの満足度だ

わーい単体テスト自動化できたーとこれで安心だーなんていってるのはレベルが低すぎるんだよ
高卒ならそれで良いかも知れないが大卒はそんなことやっちゃダメ

大局を見よ、戦略を練れ、竹槍にこだわって戦争に勝とうとするな

>>239
まぁ、自動化以前のところで詰まってる人は多いかも。

リファクタリング、単体テストを頑張る人間は一生クリエイティブな仕事できない
ユーザはネジの品質なんて気にしない、プロダクトが使いやすいかどうかが全て
ユーザ目線に立って生産性の高いアジャイルな仕事を成功させるためには自己満足を捨てて
顧客満足を選ばなければいけない

単体テストの自動化を目的に仕事してる人がいる、IT業界のマナー講師だ
嘘をバラマキ生産性を下げる原因だ、出会ったら心から軽蔑してあげよう

>>243
アジャイルなのに単体テストに意義を見いだせないって終わってるな。しかも、自動化スレでこんな発言だもんな。
アジャイルという言葉を理解していなさそう。

>>248
アジャイル == 単体テストと思ってそうｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗザ・ガラパゴスって感じｗｗｗｗｗｗｗｗｗｗｗ

アジャイル == ユーザ
これが本当のアジャイル
ユーザが見るのは単体テストの結果じゃない、プロダクト

>>249
そういえば、お前、昨日220の質問で逃げてたけど、答えないの？

まともな企業で仕事してみ、総合テストを重視したほうが品質高まるねってのが常識だから

>>243
>日本の仕事の生産性が低いのも細かいところで頑張って全体の品質から目を背けているからだ
>開発者が力を注ぐべきはプロダクトでありユーザの満足度だ
なんでアジャイル開発やTDDに発展していったかっていう経緯が全然分かってないやん
単体テスト無しで各コードが密結合されたプログラムの場合、変更のコストが膨大になる(作業工数の膨大）
で、プログラムっていうのは常に変化するものだ
不具合対応だけでなく、それこそユーザー要望によってコードはどんどん追加される

で、そのユーザーを満足さえるためにコードを変更するって事は仕様追加だけでなくて、既存仕様の担保も同時に必要になるんだよ
密結合されたコードは修正時の影響範囲が大きく、容易に変更する事が出来ない
何より変更後の既存仕様の担保っていう点で言えば、全てを保証するためには膨大なテストが必要になる

単体テストを『ちゃんと』作ると、プログラムは自然と疎結合になっていく（なぜならそうしないとテスト自体が書けないので）
更に仕様変更後も単体テストを動かす事で、少なくとも単体テストを実装している個所については
変更前後の動きを担保する事が出来る
もし抜けがあれば追加すれば良い、そうすれば次からはそこは抜け落ちない

つまり最初の工数こそかかるが、リリース後の保守/仕様変更に強いプログラムが出来上がる
これは長期的に見ればユーザーにも開発者にとっても大きな利点

お前はリリースした後の長期的な観点が抜け落ちてるからこそ、単体テストを軽視してるんだろ
ウォーターフォール式の開発で技術者寄せ集めてでプロジェクト終わったさー解散、ってやってるような奴だなとしか思えん
……というか調べたけど、テスラのロケットがシミュレーション止めたっていう話自体全然出てこないんだが……

>>239
単体テストは基本設計者がやるから
自動化環境の導入は片手間じゃなかなか難しいからうちは専任の部隊がいる
一旦入れれば次からはそんなに苦労しないんだけど最初のハードルはちょい高めやね

>>242
NGしとけ

というかユーザーは単体テストを見ない、だから単体テストは不要
っていうのは恐ろしいほどの暴論だぞ

ユーザーが必要としている領域と、開発側で必要としている領域は一致しない部分が出てくるんだから
全く理由になって無いぞ

>>253
密結合ｗｗｗｗ疎結合ｗｗｗｗいかにも10年前の本に書いてそうなことだなｗｗｗｗｗｗ
単体テストがないから設計ができないなら設計力が足りてないわ
単体テストしてる場合じゃないプロダクトと向き合えユーザと向き合え
単体テストでパソコンと向き合ってんじゃねえｗｗｗｗｗ

>>256
じゃあ単体テスト不要の根拠になるソース出して？
>>154辺りの本が古いのであれば、当然当たらしいやつがあるんだよな？
ソースが無けりゃただの妄言だぞ

>>253
密結合されたコードの破壊力はヤバいね。
何がやばいかって、最悪、1から作り直しになるから。
そして、そんなコードを作る人達がリファクタリングしたり再設計させたところで同じことを繰り返すから。
俺の会社の過去最高のクソプロジェクト案件が脳裏に浮かんだよ。

まぁ、あんたの言うとおりだわな。

>>255
> ユーザーが必要としている領域と、開発側で必要としている領域は一致しない部分が出てくるんだから
> 全く理由になって無いぞ

全くそのとおりだ。

>>257
まともな会社で仕事してみ
総合テスト > 結合テスト >>>>>>>>>>>>>>>>>>> 単体テスト
品質を左右する優先度はこれ

>>259
優先度の話かこれ？

単体テストはコーダの自己満を超えられないのよ
もっと広い視野でプロダクト全体を見渡さないとよいプロダクトは作れない
プロダクト売るのはコーダじゃないから気にしたことないだろうけど
分析してみるとユーザの満足度に単体テストレベルの些末なことは一切関与しない

たとえカバレッジ120%であってもユーザビリティが低ければ使われない
ユーザの満足度とコーダの満足度は違うもの
UIを洗練させ機能を洗練させユーザが本当に求めてるのは何かと
考え続けることがプロダクトの品質を高めることに繋がる
それがユーザと向き合うってこと、パソコンと向き合ってるだけじゃダメ

ソースは明かせないが、信頼できるとある専門から聞いたという話では
単体テストをやればやるほど売上が下がることが明らかになったそうだ

な？そういうことなんだよ

>>262
たとえカバレッジ120%であってもユーザビリティが低ければ使われない

それなら

たとえカバレッジ120%であってもユーザビリティを高くすればいいだけでは？

バカエッチ120%

目的はユーザを満足させることであり単体テストはその手段として
使われるのだけれども単体テスト頑張ってもユーザの満足度あがらんね
それはどうしてだろうプロダクトの品質があがるわけじゃないからだってのが
20年前～10年前まで単体テストを頑張って得られた結論
いまは結合テスト、総合テストを自動化して品質を高めるのが主流

10年前の知識で頑張ってるお前らは俺を煽ることでどうにか今の技術を聞き出そうとしてる情けない人たち

本を読んでPCと向き合うとことしかしてこなかったお前らの限界
ユーザと向き合うことを避けてきた根暗なコミュ障に開発の最先端は無理

なんかヤベー奴沸いてるからこれ貼っとくわ。

詭弁の特徴のガイドライン

1.事実に対して仮定を持ち出す
2.ごくまれな反例をとりあげる
3.自分に有利な将来像を予想する
4.主観で決め付ける
5.資料を示さず自論が支持されていると思わせる
6.一見関係ありそうで関係ない話を始める
7.陰謀であると力説する
8.知能障害を起こす
9.自分の見解を述べずに人格批判をする
10.ありえない解決策を図る
11.レッテル貼りをする
12.決着した話を経緯を無視して蒸し返す
13.勝利宣言をする
14.細かい部分のミスを指摘し相手を無知と認識させる
15.新しい概念が全て正しいのだとミスリードする
16.全てか無かで途中を認めないか、あえて無視する
17.勝手に極論化して、結論の正当性に疑問を呈する
18.自分で話をずらしておいて、「話をずらすな」と相手を批難する
19.権威主義に陥って話を聞かなくなる

>>259
まともな会社ってどこ？
お前の勤める自宅警備会社？

>>268
昨日の昼間からム板に張り付いている人に言われても説得力ねぇわ。
そしてそれと同じくらい、お前の50を超えるレスに説得力ねぇわ。

ツッコミを入れる周囲の人達の発言のほうが説得力があるね。
もう少し自分を疑うことをおすすめするよ。

>>259
はい、ソース無し
というか単体テストすらまともに実装出来ない会社の間違いじゃないの？

>>266
> 目的はユーザを満足させることであり単体テストはその手段として
> 使われるのだけれども単体テスト頑張ってもユーザの満足度あがらんね

だから両方やればいいだけでしょ？

マジで無能な働き者感半端なさ過ぎて洒落にならんな>ID:IgGP+BQU
あんまり煽るのは趣味じゃないが、流石にここまで酷いと思わんかった

>いまは結合テスト、総合テストを自動化して品質を高めるのが主流
本当に聞きかじりばっかだなお前
結合テスト/総合テストの自動化は開発の最終盤(UI含めてほぼ構成が固まった段階)に辺りからやるもんだぞ
さらに大前提として結合/総合時に自動化に耐えうるレベルでバグを潰しておく必要がある
つまり、単体テストで予めて一通りの品質が担保出来てなきゃ、自動化なんざ夢のまた夢だぞ

>>266
> 目的はユーザーを満足させることであり単体テストはその手段として使われるのだけれど

最終的にはそうなるかもしれないが、あくまでも単体テストの目的は詳細設計の妥当性確認では？

お前、>>253のツッコミをミスリードしてないかw？
時代遅れとか以前に、単体テストが何を目的とするのかすらわかってないじゃん。

>>273の言うとおり、両方やればいいだけだよ。そして、両方やる必要がある時点で他のテストとは目的が違うんだよ？理解してる？

更に言うと、実行時間って言う面においては自動化を含めても
単体テスト>>結合テスト>>>>>総合テストっていう絶対に崩せない不等式がある
（総合テストはseleniu辺りを使ったものを自動化を想定してる）
単体テストはフィードバック速度が段違いに早いんだよ、だからアジャイル開発やTDDにおいても重要なファクターとなる

あとずーーーーーーと引っかかってたんだけどさ
単体テスト、結合テスト、総合テストは仕様通りに動くかどうかであって、ユーザー満足度とは何も関係無いぞ
仕様通る作成できている＝ユーザーも大満足する、にならないからウォーターフォールだとダメって風潮になってるんやん
（ユーザーの声が最後の最後にしか出てこないから、フィードバックを反映するのが困難なため）

ユーザーが満足するか、使いやすいかっていう判断をするのはユーザービリティテストっていう
評価観点が全く異なるテストを実施しないといかんのだぞ
流石に二日待っても『ユーザービリティテスト』って言葉が一回も出てこないから本気で心配してるんだぞこっちは

>>276
結合テストの段階でユーザも巻き込んでやるだろ
お前のとこやってないの？ それアジャイルじゃないよ
ただのウォーターフォールだよ、どうりで単体テスト重視してるわけだわな
ユーザと会うことさえない下っ端仕事しかしてないんだろ

アジャイルとはユーザと一体化して共同でプロダクトを作り上げるものだ

パソコンと向き合ってれば良い仕事って気楽でいいなｗｗｗｗ
プロダクトの品質気にしなくていいし顧客満足も気にしなくて良いもんな
うらやましいわｗｗｗｗｗｗ

10年前の本実践してイキってれば良いもんなｗｗｗｗｗｗｗほんまええなーｗｗｗｗｗｗ

こんなにム板の住人多数から集中砲火を受けてもレスできる図太さに驚きが隠せない。

>>277
け、結合テストにユーザーを巻き込むwwwwwwwwww
ちょっと想像の斜め上どころの解答じゃなかったな
アジャイル開発でもそんなクレイジーな事せんわ
なんで結合テストしてない代物をユーザーと一緒にテストするなんて言うトチ狂った発想が出てくるんだよ
お前の開発環境クレイジーすぎるだろ……

>>282
アジャイルでは次の優先度でテストをやります
総合テスト > 結合テスト >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 単体テスト

ちなみにお前がアジャイルやったことないのは明らかで
盛大に勘違いしてそうだから老婆心で教えてやるけど
アジャイルでは総合テストを結合テストよりも先にやるからな

総合的に使い物にならないものを詳細までテストするのは時間と金の無駄だから
ウォータフォールと真逆のことをやってユーザの満足度を最優先にしてプロダクトに反映する
これを全体最適化と言う

ガラパゴスジャパンのものづくりにはその俯瞰的な視点が抜けてるから欧米にはまだまだ追いつけない
過去の慣習からいまだに抜け出せずに10年前の本をありがたがっている人もいるくらい残念な状況

>>283
>ちなみにお前がアジャイルやったことないのは明らかで

お前のことだろ。

そう、いうなればいまだに単体テストを頑張ってるプログラマはさながらハンコ議員連盟みたいなもの
時代遅れの技術にいつまでもしがみついて進歩を遅らせてるってこと
愚鈍で低能な人間は日本の未来を暗くするだけ、ノロマの罪で逮捕して冷たい牢獄で一生を過ごして欲しいくらいだわ

>>286
それじゃいまだにログを目視で頑張って眺めてそれっぽい値ならOKなんて言ってるやつはどうなるの？

>>287
それはありだろ、ログは大事だ

単体テスト（自動テスト）で正しい値と比較 vs 目視確認でそれっぽい値かどうかチェック

って話だったの忘れたのかな？ｗ

>>288
そんなことしてたらユーザビリティテストする時間なくなるやんｗ

>>289
結局最後に頼れるのは人間の目だからな
何のために目が付いてるか考えろ
ログを見るためだろうが

しかもそれっぽい値かどうかしか確認しないからバグだったとしてもわからんし

正しい答えがわからないからログに記録されているのがバグだったとしても
それっぽい値ならOKにするんでしたっけ？ｗ

>>286
その理屈だとプロジェクト作成時にテストコード記載場所を用意するAndroid Studioは時代遅れってことになるな。
つまり、Androidは時代遅れと。

>>291
見てどうするの？

お前に見張り番頼んだら、盗まれていくのを見てましたって言いそうｗ

訂正

>>291
ログ見てどうするの？

お前に見張り番頼んだら、盗まれていくのを見てましたって言いそうｗ

>>281
相手するなよ…

>>283
>総合テスト > 結合テスト >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 単体テスト
はーまたソース無し

IPA辺りの資料だけど、アジャイル開発の進め方見てみ？
https://www.ipa.go.jp/files/000065606.pdf
9ページにはTDDを基本にするって書いてあるやろ？
つまり単体テストを避けて通れないの

あと先進的な設計・検証技術の適用事例報告書 2015 年度版の資料
https://www.ipa.go.jp/files/000049403.pdf
ここに単体テストの有用性を検証した結果出てるぞ、15ページな

それっぽい言葉で誤魔化してるつもりかもしれんが
何ども言うがソースが無いなら一切妄言と変わらんからな

>>296
そうするか、NG登録しよ。
荒らしとしてBANされることを祈ろう。

まあ、なんとなく言うこともわからないでもない

結局、単体テストのチェック項目は言うほど明確にならないってことだな
浮動小数点の変数1つとっても厳密にやると恐ろしく時間がかかる
彼も全くなんのチェックもしないわけではないだろう
ただ、リリース毎に走らせるような仕組みなんか無駄なコストだと思う
もちろん動かないなんてのは言語道断だがそれは従来のテストで不十分か？と言えばそんなことはないと思う
それよりは結合で出る他のモジュールとの不整合や
総合で出る使い勝手の悪さの修正などに時間をかけた方がいいと思う
さらに言えばリリースしたあともユーザが使ってないような機能なんていっそ小規模な不具合があってもほっといてもいいのではないか？とは俺も思う

もちろん動かないなんてのは言語道断だが

部品のテストをいくら頑張ってもロケットは飛ばないというのは正しいと思う
まあ、これで悩むのは請けた仕事がそこまで判断するような広範囲な仕事だけだが

もしかして　自作自演？

なんじゃこのオチはwww

おい、ためしにlgGP+BQUは何か書き込んでみろ(原爆投下)。

>>299
>結局、単体テストのチェック項目は言うほど明確にならないってことだな
>浮動小数点の変数1つとっても厳密にやると恐ろしく時間がかかる
一回仕様決めてテスト書いたら
後はもう1関数辺り数秒にも満たない実行時間しか無いぞ……

つか浮動小数点のテストなんてそこれそユニットテストで良くやるやつやん

なんの作戦もなく単体テストの自動化を勧めてくるペテン師に引っかかってはならないというのはガチだと思う

・自動化Scriptの作成コストはでかい
・単体テストよりもうちょっと上の階層のテストの自動化の方がよくないか？
・そんなに何度も単体テストしないし
・かけたコストに対するリターンが小さそう？

>>304
まともな人が居てうれしい

>>303
すげー大変じゃん
仕様を定義するやつも
小数点いくつで四捨五入なのか切り捨てなのか全部考えないと
でもそんなことしなくてもプログラムって動くし
んでこういうのって会社で一旦やるって定義されちゃうと全部やらないといけなくなっちゃう
でも大半は必要ない

>>304
>・自動化Scriptの作成コストはでかい
それは正しいが、テスト自動化の作成/修正コストは
　総合>>結合>>単体テストの関係になる
　(必要な構成、モジュールが総合テストに近づくほど増えて影響範囲がどうしても増えるので）

>・単体テストよりもうちょっと上の階層のテストの自動化の方がよくないか？
　総合/結合テストの自動化はバグを発見するのが目的ではなく
　既存機能が壊れてないを確認するために使うんだぞ？
　勘違いしてる人が要るかもしれんが、総合/結合テストでバグが頻発すると
　テストが失敗した原因の調査～修正の作業に無視できない工数がかかるから、
　作成コストが少ない単体テストが整備出来てなきゃ宝の持ち腐れだぞ

>・そんなに何度も単体テストしないし
　それは単純にサボってるだけ
　継続的デリバリーとか継続的インテグレーションっていうスタンスで立つ場合
　CIツール、例えばJenkins辺りで構築する場合
　ソースをコミットしたタイミングで、コード解析、自動ユニットテスト、ビルドまで一連でやるようにする
　だから一番動かすのはむしろ単体テストになる
　https://www.techmatrix.co.jp/product/cisolution/service/index.html
　https://tracpath.com/works/devops/continuous-integration/

>・かけたコストに対するリターンが小さそう？
　んな事ない
　上記の例も合わせてリターンは大きい

自演成りすましかとも思ったが本物だった
幼稚過ぎるやろ

>>307
自動テストは単体が一番作るの大変だと思うけどなｗ
結合や総合はモジュールや機材のセッティングは大変だけど
作るのは簡単やろ
だってUWSCで画面のボタンをポチって押すだけやろ

少なくとも俺はそんなイメージだけど？

>>309
うーん、もしかして受託開発？

>>309
>作るのは簡単やろ
>だってUWSCで画面のボタンをポチって押すだけやろ
それは考えが甘すぎだわwwwwwwwwww
それだと操作しかしてないやん

UI周りの自動テストを実装する場合
・テストシナリオ(どういう操作をするのか）
・テストの判定基準
　(想定通りの画面に遷移しているのか、表示されるメッセージが正しいか、データ登録が絡むならその結果も正しいのかなど）
・テスト結果の判別方法
　(これはテストシナリオによって変わってくる、登録データをそのまま引っ張り出すならDB接続して想定値との乖離が無いかチェックする
　ものによっては画面キャプチャで画像差分を見るってやり方もあるけど個人的には好きじゃない）


最低でもこの辺を意識して作らんといかんから、
そんな画面ポチポチ終わりーでいかんぞ…・…
特にUIの自動化は変更に弱い認識だから、本当に最後の最後で実装しないと地獄を見るし

>>307
単体テストのモジュールってさ
上流で変更があると枝葉って変更じゃなくて消滅と生成のが多くない？
そうなると実ははじめの一回目しか実は見てないんじゃない？って俺は思っちゃうんだよね

枝葉をくっつける本流の方が間違ってるときってそれそもそも自動化以前にテストやっとるのかと？

俺は単体テストの自動化テストはヒット数（実際にバグを捕まえた数）は少ないと思ってる
苦労した割には

Ruby on Rails のRSpec で有名な、ソニックガーデンの伊藤淳一とか、
Serverspec の作者・宮下剛輔とか、有名

YouTube で有名な、雑食系エンジニア・KENTA は、
初心者のRailsポートフォリオに、CircleCI まで入れれば、有利と言ってるし

有名は人は皆、BDD の鬼！

>>312
単体テストでバグの発見数は正直重要じゃないな
というかそんなん集計とるか？
普通は単体テストが成功してからコミットするし、テストコード無しでコミットしようとしたらプログラマー〆るだろ

……というか仕様変更の度に関数が消滅と生成が起きるって
それはどっちかと言うとプロジェクトの問題では……？

>>311
総合や結合の結果の判別なんか
ログの最後の出力がCompleteだったぐらいでええやろ
機材がクソってるのにログにCompleteって出てるならそれってテストScriptのせいじゃなくてそもそもログ出力腐ってるやろ？

>>314
きっちりメソッドが分けられず
他の機能と融合してるから
変更が多いんやろ
普通は上流の変更があったら枝葉のメソッドは生成と消滅が多い

>>306
そこは仕様によるし、あと責務の分割とかそういう発想でプログラムを組めばいい

超簡単な例として、電卓を上げるぞ
win10の電卓を叩くと
10/3 =　3.3333333333333333333333333333333
20/3 = 6.6666666666666666666666666666667
っていう感じで小数点31桁で出てくる

この結果から以下の仕様が読み取れる
・計算した結果が無限小数の場合、小数点は31桁まで表示する
・小数点31桁目は四捨五入して表示する
っていう仕様が予測できる

と言う事は、最低限の実装方針としては以下のようにすると、楽に単体テストが実装できる
・計算ロジック側は小数点31桁よりも大きい桁数でユニットテストは判定すれば良い、単体テストは可能だし、変更も簡単にチェックできる
・画面表示をする際に小数点31桁として出力するように四捨五入するメソッドを実装してかませればいい、このメソッドも単体テストが可能になる

ようは必ずしもすべての計算結果の小数点桁を指定する必要は無い、基本的には余裕のある実装にしておけば早々壊れない

>>315
それはテストツールによるとしか言えん
ちゃんとしたGUIテストツール使って、シナリオも確認してるのであれば
もちろんばログレベルの確認で良い

ただUWSCって名前が出たからついな
あれは自動操作用の目的だし、そもそも今開発止まってるから使うべきツールではない

>>314
テストコードコミットしたらぶっ殺すわｗ 仕事しろと

自己満は趣味でやれ、仕事でテストコード書くなと

複数の下流工程を管理する際、テストコードの無い成果物を渡されても、そのソフトウェアモジュールを製品に組み込んでもいいのか判断に困る。

そもそも、単体テストが済んでいるということは、そのソフトウェアモジュールはテスト仕様の範囲では正しく動くことが保証されているわけだ。

だから、完璧な単体テストさえ行っておけば、完璧なモジュールを組み合わせて完璧な製品が出来上がるから、理論上完璧な単体テストができれば結合試験すらいらないんじゃないなって思う。(流石に大胆発言か？)
※顧客満足のチェックまでは無理だが。
※ここで言う完璧なモジュールというのは組み合わせれば理想な製品ができるモジュールのこと。(前提条件がシュールすぎる？)

まぁ、現実的に人が設計をする以上、仮に一つ一つのモジュールがテスト仕様書を満たしたところで組み合わせても上手くいく保証はないから結合テストもやるんだが...。

単体テストについては、こんなイメージだな。

プロならテストコード書かなくても動くコード書くのが普通
単体テスト書くことが目的化してしまってるのがマナー講師と呼ばれる所以

>>321
単体テストは時間の無駄だから
単体テストのテストコード見て判断する木偶の坊が管理してるとかそのプロジェクト破綻してるだろｗｗｗｗｗｗｗｗｗｗｗｗ
大局を見ろよ、設計として正しいかどうかで判断しろ、単体テストのテストコード見てどうするんだバカｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ笑い死にさせる気かｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

なんか、さっそく、あぼーんされている奴が沸いてるんだけど。
ごめんね。俺のブラウザだと、NGが共有されるから、読めないや。

「単体テストのコードがあるな、よし！」とか言ってるのかｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗ現場猫かよバカがｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>324
見てるくせにｗｗｗｗｗNG解除してみてるくせにｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗハゲワロｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

お前ら笑いの才能だけはあるよなｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗすげーわ単体テストのテストコード見て管理した気になってるとかｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗ次元が違うわｗｗｗｗｗｗｗｗｗｗｗｗ

>>322
適当に有名処のフレームワークのGithub覗いて来たけどさ
がっつりユニットテストコード書いてるけどね、仕事として
それとも今でも一線で活躍してるフレームワークをまた10年前のシステム～とかで良い訳でもするん？
あ、オープンソースだから参考にならないっていうかもしれないな！

Djangoフレームワーク(python)
https://github.com/django/django/tree/master/tests
コード例
https://github.com/django/django/blob/master/tests/admin_scripts/tests.py

Springフレームワーク(java)
https://github.com/spring-projects/spring-framework/tree/163b97f1ff44b4239f1e66ea5228c68b4bef729b/spring-test/src/test/java/org/springframework/test
コード例
https://github.com/spring-projects/spring-framework/blob/163b97f1ff44b4239f1e66ea5228c68b4bef729b/spring-test/src/test/java/org/springframework/test/context/TestExecutionListenersTests.java

>>328
ロクなテストしてないな、やっぱ単体テスト無駄だわ、そのテストなくても問題ない
いいよなーオープンソースは気楽でよー、人件費なんて無限に湧いて出るようなもんだもんなー
お前のようなアホが実績欲しさに無駄なコード書いてくれるもんなーいいなーうらやましいなー
無駄なテストコード書いて時間つぶして居られるなんて幸せものだなー

無駄なコードでも大変だから仕事した気になれるんだろうなーやりがいはありそうだよねーｗｗｗｗｗ
ｗｗｗｗｗｗｗｗ一銭の価値もないけどｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

お前ら授業中に真面目にノート取って先生に褒められて勉強できる気になってそうｗｗｗｗｗｗ

でも高卒どまりｗｗｗｗｗ

>>328
有名どころのテストコードを見たことが無かったけど、思ったより普通だった。

でも、まぁ、勉強になる。

>>329
>ロクなテストしてないな、やっぱ単体テスト無駄だわ、そのテストなくても問題ない

「この単体テストは無駄、不要」っていう判断を下すには以下を知って無きゃいけない
・テスト対象のコード仕様
・テストコードの内容
先に言っておくが、無駄なテストコードっていうのはもちろん存在するぜ
テストカバレッジを水増しするようなコードとかな

あんたは3分足らずで言語仕様も異なる二つのフレームワークのソースを見て
コードの仕様とテストコードを理解して文句を付けてるわけだ
いやー、すごいすごい、単体テスト不要派なのにめちゃくちゃ詳しいんですねー

あ、ちなみにだけどさ『2020年』のWeb調査で
次に学ぶべきWebフレームワークの人気ランキングで
Djangoは3位、Springは7位につけてるぐらい人気があるフレームワークなんで
https://info.hackerrank.com/rs/487-WAY-049/images/HackerRank-2020-Developer-Skills-Report.pdf

あ、1位のReact、2位のAngularもテストコードは実装してるぞ
(自分がJavaScript使ってないからあんまりこの辺のコードは読まない）
React
https://github.com/facebook/react/tree/9025949d840c89619bed9bf06f5c14c25c141c5a/scripts/jest
Angular
https://github.com/angular/angular.js/tree/master/test

しかしまさか有名なオープンソースすら否定すると思わんかったわ
一体何を根拠にその自信が持てるのか分からん

あと中々面白いのがこれだな
https://github.com/JetBrains/intellij-community
やまほどテストコードが転がってるから読み込むだけでもいい勉強になる
テストフォルダが細かく切られてるから読み解くのがちょっと大変だが
https://github.com/JetBrains/intellij-community/blob/master/python/testSrc/com/jetbrains/python/PyBlockEvaluatorTest.java

個人的にはDjangoのテストフォルダの構成が一番読みやすかった

PythonのテストフレームワークでPyTestっていうのがあるんだけど
サンプルコードが少ないっていう問題があるんだが
その時はPyTestのgithubを見ると良い
https://github.com/pytest-dev/pytest/tree/master/testing
なんとPytestはPytestでテストしてるから、これを読み込むのが一番良かった
何より分かりやすい

日本では、この2人がBDD の鬼！

Ruby on Rails のRSpec で有名な、ソニックガーデンの伊藤淳一は、
RSpec の本、Everyday Rails も翻訳してるし、

Serverspec の作者・宮下剛輔も、有名

結局オープンソースとか有名プロジェクトは
単体テストを行うのは最低限の常識レベルになってるんだな

あ、もちろん単体テストを自動テストするって話ね
手動だったら単体テストやってるなんてこと外部からわからないから当然かｗ

手動テストの問題はコストがかかること
人海戦術でやるという発想でコスト意識がないのだろう
だいたいこういう所は客が金を出してる。つまり自分の懐は傷まないｗ

コストがかかる手動テストのプロジェクトでのコスト削減の発想はテストが必要なることをやらないこと
ソースコードを修正するとテストが必要になる。つまり極力ソースコードを修正しない。
こういうところは未だにIEじゃないと対応してませんとかやってる。
作って検証ができないからユーザビリティも悪い

Google map

https://github.com/googlemaps/android-maps-utils/blob/master/library/src/test/java/com/google/maps/android/PolyUtilTest.java#L7

調べると事例なんて腐るほどあるな。

ただ、いまいち自動化という言葉の意味がわからない(ただの無知)。
有償のテストツールを使ったことないけど...自動化とは言えど、テストコードを記述してビルドして実行することには変わりがないのだろう？
無知故の疑問だが、自動化と非自動化の差って何だ？

>>342
「ちゃんとテストしたのか？」

・自動化
「はい、ここにテストした内容が書いてあります。これを実行しました。
テストに通ったことはテストの実行結果から判断できます。
もう一回やってみろって？コマンドを実行するだけですのですぐ終わります。」

・非自動化
「はい、ここにテストした証拠のスクショがあります。手順通りに実行してOKっぽかったからチェックを入れました。
テストに通ったかどうか？手順通りにやりましたよ！スクショがあるんだから信じてください。
もう一回やってみろって？全部ですか！？何時間、いえ何日かかると思ってるんですか！」

>>343
エビデンスは？

>>344
あなたがもう一回実行すればいい
あなたもすぐにテストを実行したというエビデンスを作ることができる

>>345
じゃあ、作業未完了だね
納品物にエビデンスって書いてあるじゃん

>>346
実行した姿をビデオカメラに写しておけばいいだけでは？
このテスト、私が実行しましたってｗｗｗ

それ以外に何が欲しいんですかねぇ

エビデンスが要求される粒度のテストのためにエビデンス生成フレームワーク作っとくと便利よ

もちろん1番大事なのは自動テストの性質に合わせたエビデンスの形態を定義して、客に受け入れさせる営業力だが

日曜だから市場で買ったカニの出汁を濃縮してるわ、冷凍してとっとくんだ
これがホントのカニdense

>>349
テスト自動化のほうが安くなります。
手動で作業したらその分時間がかかります。
スクショとったらその分時間がかかります。
しかもそのとったスクショ、あなた全部検収するんですか？
みたいにいえばOK

金と手間がかかる問題を客に押し付ければ意見は通る

>>351
ええ、そうですよ

UIの自動テストはスクショもログ＋スクショ自動生成までやってくれるから
本当にエクセルに張り付ける作業は不要なんだよな
スクショ張り付け作業をこれやらされる新人はマジで悲惨

しまいにゃ手動でやれば、バグがあって金がかかろうとも、丁寧な作業をしてると客を騙しはじめるのだろうな

ていうか自動化にエビデンス入ってねぇのかよ
客に出せるレポートなんか出んだろフツー

エビデンスは手作業で取るもの。自動で撮って誰が確認するというんだ？
客はエビデンスがあることを見てるだけで内容までは確認しないものだぞ

エビデンス撮った本人が、よくわからんが、まあバグっぽくない画面で動いてるからヨシ！ってやって
やっとエビデンスの意味があるというものだろう

ログでもいいやん
正しく動く証明になれば

Firefox for iOS
https://github.com/mozilla-mobile/firefox-ios

Wire (エビデンスあり)
https://github.com/wireapp/wire-ios

kickstarter (エビデンスあり)
https://github.com/kickstarter/ios-oss

ログが正しく動いてることを証明するエビデンスが必要

そのエビデンスが正しいことを証明するエビデンスが必要

さらにそのエビデンスが正しい・・・

>>357
ログはたんなる実行結果に過ぎないから正しく動く証明にはなることはないよ

ログを正しく動く証明にするには方法は２つ
1. ログを取った担当者が、それをみて判断する
2. ログを取った人と別の人が担当者が、それをみて判断する

どちらが判断するにしても、正しい答えを知らなければ正しく動くと証明することはできない
だから上の方で言っていた正しい答えなんか事前にわかるわけ無いだろ！それっぽい値ならそれでいいだろ！
なんてのは問題外なわけ。正しく動く証明をしてないわけだから

スクショなんかも、取ったってそれみて後から検証なんかしないでしょ？
今からスクショみてバグが表示されてないか見ますなんてしないでしょ？

あれは仕事サボってないかとかいう作業完了報告書だったり、なにか問題が
起きたときにちゃんとやったのかという責任追及をするための道具に過ぎないよ
かろうじてバグがあったという証明ができるぐらい。正しく動く証明ではなくバグが有ったという証明ね

まあつまりログとっただけでは何の証明にもならないって話
ログと正しい答えを目視で比較する vs コンピュータでログを自動的に比較する（それが自動テスト）の違いよ
人力で比較してりゃ時間もかかるしミスもある。何もいいことはないね

>>360
いや、ログ出力のテスト通ってるし

ログって言葉が独り歩きしてるけど
基本的に自動テストって
・想定通り動いた＝OK出力(グリーン)
・想定通り動いていない＝ＮＧ出力(レッド）
の2観点しかない

自動テストは結果判定もしてるから、実行だけ成功＝OKには絶対にならん
(そんなテストを実装してたらぶっ殺されるわ）

で、自動テストのログが当てにならないっていう人って
無意識に以下のパターンを想定してるんだよね
・想定通りに動いて無いにも関わらず、OK出力(グリーン)が出ている可能性がある
つまりテスト側の不具合を懸念して、それでバグを取りこぼす危険性を考えているわけだ

結論的に言うと、そういうのはテスト作り方の問題になるし
発生するとのは相当なレアケースになる
というかこれが頻発してるなら、自動テスト組んだプログラマはクビにしろ
正しくOK/NGが判定できない自動テストならそりゃテストになってねえ

万が一、このレアケース発生しても修正をすればいいだけの話で、クリティカルな問題に発展する事はほぼ無い
(むしろ人間によるチェックの方が、判定の曖昧さ、ミス隠し、スクショ偽造とか色々やってくるから個人的に信頼出来ん）

>>361
ログ出力のテストって何？

ログの話は「ログ見て人力で目視比較してそれっぽい値ならOK」ってやつでしょ
ログに出力した後に人力比較があるんだよ

>>363
ログ出力だって機能の一つなんだからテストするでしょ？
ちゃんと指定通りのフォーマットで出てるかどうか？
日時、種別、内容などなどね
しないの？

するわけねえわｗｗｗユーザと関係ないだろうがバカがｗｗｗｗｗ

何のためのテストだよｗｗｗｗｗｗ
意味のないテストやって尺稼ぎしてんじゃねえぞ経営者目線で仕事しろ

ユーザと関係ないところで一生懸命頑張っても誰も認めねえからな
売上に一ミリも寄与しないこと頑張ってどうするんだｗｗｗｗｗｗｗｗｗ
ｗｗｗｗユーザから目をそらすために関係ないこと頑張ってるんだろｗｗｗｗｗｗ
パソコンが好きなだけじゃ会社は成り立たねえんだよｗｗｗｗｗｗｗｗｗ

>>364
> ログ出力だって機能の一つなんだからテストするでしょ？
わざとかもしれないけど（笑）話がすり替わってる

ログ出力機能のテストの話じゃなくて
○○機能のテストをするとき、その機能の結果をログに出力して
その出力を目視で人力比較してテストするのはアホという話をしてる

単体テストのテストコード書くほうが100倍アホだからｗｗｗｗｗｗ
ｗｗｗｗｗｗｗそこんとこ忘れんといてよｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

自動テストでも実行結果をログに出力できるわけで
コンピュータで「比較」までやるか、人力で「比較」するか
誰が「比較」するのか？が違う所なんだよね

なんかよくわからないところに噛み付いてるのでスルー

wの数と知能の高さは反比例するらしい

これの話だからな

289 自分：デフォルトの名無しさん[sage] 投稿日：2020/09/26(土) 20:50:49.34 ID:c/9EiqGf [4/8]
単体テスト（自動テスト）で正しい値と比較 vs 目視確認でそれっぽい値かどうかチェック

って話だったの忘れたのかな？ｗ

291 返信：デフォルトの名無しさん[] 投稿日：2020/09/26(土) 20:52:18.62 ID:IgGP+BQU [29/30]
>>289
結局最後に頼れるのは人間の目だからな
何のために目が付いてるか考えろ
ログを見るためだろうが

関数の入力仕様と出力仕様が明確なら
ログ出力関数のテストは簡単

でもログ出力関数を使う処理が正しくログ出力してるかどうかのテストはそう簡単ではない

なぜならログ出力の正しさを判定するためにはログ出力以外の結果は正しいということが事前にわかってなければいけないから

つまりログ出力だけでは処理の正しさを証明することは出来ない

テストで「正しいと証明できる」という考え自体がある種の幻想

このスレ見てると一体どういう自動テストを実装してて
どういうログを流してるのか本当に気になるわ
そんな突き抜けバグ(不具合起きてるのに何故か正常終了扱いになってる状態）を抱えた自動テストばっかり使ってるの？

本当にどういう自動テストを想定してるのか分からん
まさかログに値だけ出して、後でその値が正しいのか人間がチェックしてるのか？
それ自動テストじゃなくて、ただの自動実行だよ
テストっていうならグリーン/レッド判定まで実装してなきゃ使いもんにならん

> 本当にどういう自動テストを想定してるのか分からん
> まさかログに値だけ出して、後でその値が正しいのか人間がチェックしてるのか？

ログに値だけだして～って言ってる人は、自動テストしてないよ
ログに値だけだして目視確認する手動テストでいいって言ってる
なぜなら正しい結果がわからないから

これ↓ね。こいつの言ってる意味がわからんと思うけど、意味不明だと俺も思うｗ

28 名前：デフォルトの名無しさん[sage] 投稿日：2020/09/23(水) 20:17:23.00 ID:cCwBtdaA [9/11]
テストと言いつつできるのは計算過程と処理結果を残すだけだと思ってるよ俺は
長年考えた結果
正しい値なんてのは実は物理的に誰も知りえないということを理解した

なのでテストで重視するのは俺は組んだコードのエビデンスの方
どんな処理書いてどんなログ出したか
自動テストは結局同じやつが作ってる以上同じ不具合入ってるだろうなって思ってるｗ

そろそろレス古事記に構うのをやめようか…
テストはバカだという証明はできるけど、いくら指摘しても修正しない限りバカはバカのままだし

エビデンスとはテストを端折らずに実行しましたと言う証拠であって
動作の正しさやテスト手順の正しさを証明する証拠ではない

エビデンスという名の作業ログ

自社開発ならエビデンスは要らんよ
しょせん対外的な作業証明でしかないからな
それよりテストコード、テスト可能なコードを書いてくれや

細かいことで揉めるから、
>>1のような提案をする空気だけは読めるバカが出世して管理職になんだな。この業界は

>>378
そのとおり

バグっている場合は、そのバグの様子をスクショしてるだろうからバグがあるというエビデンスにはなるだろう
しかしバグがないというエビデンスにはならない。これは自動テストでも同じだが、大きな違いは
バグってないというスクショをとっても、正しくテストを実行したというエビデンスにはならないという点

スクショ取るだけではテストケースは書いてあっても、そのテストどおりにテストをしたという証拠にはならない
最終結果だけでなく一連の動作を動画で撮影してるならまだわかるが、間違って手順でテストしたかもしれない
つまりエビデンスというのは（手順が間違ってるかもしれないけど）ちゃんと作業しましたという意味にしかならない
どういう手順でテストを実行したかという記録が含まれていない

自動テストの場合は最終結果だけでなくどういう手順でテストを実行したかが記録されている。
必要なら再実行もできる。だからこれこそが本当のエビデンスになる。

スクショには正しい手順でテストを実行したかが記録されていないのだから
作業をしましたという報告でしかない。

バグのスクショは意味があるが、正しく動きましたというスクショは必要ない
だからこれは本来この項目をテストOKでしたとチェックリストにチェックつけるだけで十分

チェックリストにOKでしたというチェックをつければ十分なことに
スクショを必要とするのは、単に作業者の報告を信用してないという意味でしかない

単体テスト書いとけば改修しても自動で既存機能が壊れてないことが確認できる
ゆえに機能の改修を心置きなくできる
テストがないと気軽に既存機能に手を入れるわけにはいかなくなる
（あたりまえ）

自動テストがないと手動テストをしないといけない
それは膨大な作業量となる
だからバグのないコードを書け、作ったら改修はするな！と叫ぶ

バグがあったときのことまで考えてない
仕様に変更があったときのことまで考えてない

一旦書いたら終わりという前提でいるやつがいる

そのほうがビジネスとしては美味しんだ
テクニカルな面で優れた手法がビジネスでも優れた手法であるとは限らない

>>385
単にビジネスが下手なだけだろ？

内部は楽をして、外部に対してこんなに頑張ってるんですよーってアピールすればいいだけ
外部に頑張りをアピールするために、実際に内部でも無駄に頑張る必要はない

>>382
>バグのスクショは意味があるが、正しく動きましたというスクショは必要ない

正しく動いてたと思っていたものに後から不具合が見つかった場合
前回テスト時のスクショがあると調査が効率的にできる
それは自動でも手動でも同じ

>スクショを必要とするのは、単に作業者の報告を信用してないという意味でしかない

個人への信用に依存したシステムはミスがあれば個人を責めることになるのですぐブラック化する
典型的なマネジメント能力不足の例

> 正しく動いてたと思っていたものに後から不具合が見つかった場合
> 前回テスト時のスクショがあると調査が効率的にできる

不具合があると既に分かった後の話ですよね？
スクショがあると、どう効率的に調査できるんですか？

>>387
> 個人への信用に依存したシステムはミスがあれば個人を責めることになるのですぐブラック化する

だから自動テストでコードにするんですよね。他の人がテスト内容をレビューできるように
スクショだと、実際どういう手順でテストしたのかが記録されてないから
ちゃんとテストしてないだろ！って個人を責めることにつながる

手動テストで問題なのが、前やったときのテストと完全に同じ状態が作れないということ
作業の順番でも状態が変わってくるから前後にやったテストによって成功したり失敗したりする

だから改めて同じと思った手順でテストしたら失敗することがある
スクショを取っていても「お前この前ちゃんとやってなかっただろ！」と責められる

>>388
自分で考えて

>>389
自動か手動かには関係ない
自動化したUIテストでスクショ取らないのかな？

>>391
UIテストってわざわざ書いたってことは
それ以外には当てはまらないって自覚してるのかなｗ

自動化したUIのテストでスクショを撮るというのはおかしな表現で
"テスト"を自動化していれば、当然自動的にテストされるわけよ
スクショはいらない

>>391が言ってることのほんとうの意味は
UIのスクショを自動で撮っているだけで
UIのテストは人が目で見てやってる手動テストだろう？

それとも違うんか？ UIのテストを人が目で見ず本当に自動化してるんか？

でもいい感じにお高いツールはUIテスト時のスクショも自動で撮ってくれるからねｗ
ないからっていらないやいって悔し涙流さなくていいぜ

別に高くなくても取ってくれるやろｗ
論点はそこじゃない
取った後どうするのかだろ

高いツール使ってるんだぜ悔しいだろ
みたいな意味かな？

>>395
撮ったあとどうするもこうするもお高いツールはクリックすればすぐ見れるんだよ
手動でエクセルに貼る作業とかないから

ただ・・・
（実はあんまり手間減らないんだけどな）

自動化は人間が楽をするために自動化してるだけなんだからログでもスクショでも何でも良いけど、テスト結果がグリーンであってもエビデンスは人間の目で検証しないとダメだよ。自動化の利点は、手動テストやってる要員や係るリソースを他のことに回せるってだけ。

自動テストがプログラマの自己満と言われる所以はテストパターンを無限に作成できるからだよ。sumAtoFで引数を6個取るなら0,0,0,0,0,0から9,9,9,9,9,9の範囲や、マイナス値とか小数点とかnull値を含めていくらでもテストパターンが作れる。しかも再実施も簡単。手動テストじゃそうはいかないからね。

>>397
見てないでテストしろよｗ

>>400
手動テストでもテストパターンは無限に作れると思うが？ｗ

>>399
> テスト結果がグリーンであってもエビデンスは人間の目で検証しないとダメだよ。
え？なんで？愛情がどうとかどうでもいい話だよｗ

>>399
あ、初めて自動化したときだけエビデンスの検証してねってこと。次の改修では追加・変更したテストパターンのエビデンスを検証する。それ以外の既存のテストパターンは結果がグリーンであればそれでデグレとしての証明は担保できてると思うよ

>>403
PGした人がテストパターンも作ってたら同じ不具合が混入する可能性があるでしょ

>>402
手動テストでも無限に作れるけど人海戦術しないとテストしきれないでしょ。テストの規模とプロジェクトによってはそんなの現実的じゃない。だから自動化のが簡単。

>>400
>自動テストがプログラマの自己満と言われる所以はテストパターンを無限に作成できるからだよ。sumAtoFで引数を6個取るなら0,0,0,0,0,0から9,9,9,9,9,9の範囲や、マイナス値とか小数点とかnull値を含めていくらでもテストパターンが作れる。しかも再実施も簡単。手動テストじゃそうはいかないからね。
流石にテストパターンの洗い出しすら考えないのは頭おかしいやろ
自動テストの実装コストもタダじゃないし
というか不要なテストパターン(重複してるテストパターン）は消すぞ普通……

というかテスト自動化で無限にテストが出来るって思ってる奴もいるのかよおおおもう

あれだな、デジタル庁も作られるんだし
品質管理の観点として、テストに関してちゃんとガイドラインと共通規格決めてくれ
頭痛くなってきた

>>408
理論上は可能だよねって話をしただけだよ。現場ではそんな無意味なテストしてないから発狂しないでよw

テストパターン考えるときに大丈夫だとは分かっていても不安だから盛り込むパターンも少しくらいはあるよねってこと。人間だもん。ちょっと多めにテストして安心したいよね。

無限に作るとか、藻舞ら、境界値テストを知らんのか？w
例えば、正常範囲を10～20 と決めたら、論理的に、9, 10, 20, 21 だけでOK のはずw

-1, 0 も、9と同じ。
11, 19 も、10, 20 と同じ
100 も、21 と同じ

こういうのを論理的思考と言う。
どれとどれが、同じグループですか？ と言う問題

>>405
> PGした人がテストパターンも作ってたら同じ不具合が混入する可能性があるでしょ

え？なんで？ｗ

テストパターンってお前コードから生成すんのか？
そもそも最初に、入力決めて、出力決めて、
そうなるように作るというのに意味がわからん

>>410
そうやって自動テストでもテストする値を決めるよね
無限に自動テストできるわけじゃないんだからさぁｗ

>>411
テストパターンを基にテストコードを書くよ。
最初に入力を決めて次に出力を決めてそうなるようにテストコードを書くよ。
テストを実行したら全部グリーンでもテストコードのコーレビューをするよ。

>>413
> テストパターンを基にテストコードを書くよ。

そのテストパターンが間違っていたらどうするんだ！

まあそういう事はあるよねｗ　テストそのものが間違ってるってこと
でもPGがテストパターンを作ると間違えるってのが意味がわからない
PGが作ってもPG以外が作っても、テストパターンを間違える可能性は変わらない


> テストを実行したら全部グリーンでもテストコードのコーレビューをするよ。
手動テストの場合どうするんだろうね。テストコードに相当するのはテスト手順なわけで
テスト手順もレビューも必要なんだが、手動テストだとテストパターンのレビューしかしてなさそうｗ
テストパターンはあってるけどテスト手順が間違っていて意味のないテストをしてたりしてな
テストするときは先にデータを初期化して、この手順でデータ作ってからやらないとだめじゃないですか！みたいな

>>413
> 最初に入力を決めて次に出力を決めてそうなるようにテストコードを書くよ。
ここは言葉が間違ってるね


× 入力を決めて次に出力を決めてそうなるようにテストコードを書くよ。
○ 入力を与えて出力が決めたとおりになってるかを確認するテストコードを書くよ

TDDではそのあとに、テストに通るように実装コードを書く

>>410
9.9999999999999999や20.000000000000001は？

境界値分析+同値分割は基本だけど
型の境界も意識しないとそのうちバグるよ

>>414
>PGが作ってもPG以外が作っても、テストパターンを間違える可能性は変わらない

コードを書いた人とそれに対するテストコードを書いた人が同じなら
同じ勘違いや同じ観点不足が発生するリスクは高まるよ

例えば>>410が書いた例で整数値以外の入力という観点が欠落してれば
コードでもその対応を書かないしテストの必要性にも考えが及ばない

ただだからといって必ず違う人が書いたほうがいいというわけじゃない
低減できるリスクと作業効率とを考えて判断するもの

>>415
あぁそのとおりだった

>>414
・PG組んだ人が一番思い込みが強いから、もしかしたら他の有識者と認識が乖離しているかもしれない。まぁレビュアがしっかりしてれば大丈夫。


・手動テストの場合は、テスト条件を満たしていることが担保できるようなスクショを取得するよ。テスト条件どおりに実施してくれたかどうかは実施者を信用するしかないね。エビデンスに細工されたら誰も気づかないと思う。
ちゃんと実施してるつもりでも実際は細かい操作とか大事な操作をミスっちゃってて、それでもたまたま予想結果と一致しちゃう事もあるかもしれない。だけどそんな偶然は滅多に起きない。後でアドホックテストもするし、結合試験や統合試験で発見できればok。

・エビデンスとテスト手順とパターンを見比べて「これは何のテストをなんだ？」って思うことは稀によくあるね。

・手動テストでテストデータが必要な場合は事前準備としてそういうデータを用意してからテスト開始するよ。

>>417
> 例えば>>410が書いた例で整数値以外の入力という観点が欠落してれば
> コードでもその対応を書かないしテストの必要性にも考えが及ばない

だからそれ、コード書かない人でも
整数値以外の入力という観点が欠落することあるじゃんって言ってる

むしろコードを書かない人のほうが、テストの必要性に考えが呼ばないことのほうが多い

「数値入れたらこういう計算してくださいね」
→ 文字入れたら？え？文字入れた時？文字なんて入るの？そんなの想定外だよ

set○○○系の値を設定するだけのメソッドってあるじゃん

ケース1:resultがOKならOKとする
ケース2:get○○○系メソッドを実行して値を確認する
ケース3:実際にその値の変更の影響をうける処理を実行して確認する

実はもう結合まで来てんだけどどうやって確認する？

あ、やってみたらget○○○系もよくわかんなかった
値取得できたけどそれが何？
何が取れると正しいの？ってのが一連の処理の流れだと取得できるべき正しい値が本気でわからん

>>421
> 実はもう結合まで来てんだけどどうやって確認する？

確認する前に結合したのが悪いって話だろ？
もうリリースしちゃったんだけどどうやってテストする？みたいな話だｗ

>>422
> 値取得できたけどそれが何？

「値取得できた」
それがテスト

（手動で）テストしてOKだったから何？と言われてもな
意味ないと思うなら（手動で）テストしないでいいんじゃない？ｗ

>>422
> 何が取れると正しいの？

そんなに作る前からわかってる話ですよね？
作ってるなら「目的」があるはずですが
あなたは一体何を作ってるんですか？

あ、あれか。教科書写経してるだけだから
自分が何を作ってるかわからないとか

んで作ってみて動かしたら・・・ゲームだった！みたいな事やってんの？ｗ

コンパイラ作ってるんだが、検査は自動でランダム構文生成とかしてやってるよ
もちろん普通の検査もやるんだけど、それだけだとパターン数が発散して検査しきれない

ランダム検査はテスト件数でいうと1000億件とかになる
不具合でるのはそのうち5件とかだったりするんだけどね

>>427
だからそれを手動でやればいいんですよ！

自動化する単体テスト＝関数単位のテスト
エビデンスをとる単体テスト＝1個の機能のテスト。例えば入力欄1個など

> エビデンスをとる単体テスト＝1個の機能のテスト。例えば入力欄1個など

その"エビデンス"でどうやって入力欄1個の機能がOKだと証明するの？
入力欄1個の機能がOKであると、誰もが認られるようなエビデンスとはどんなものが知りたい
そこに入力欄の画像が1個あったって、機能が満たされてるかなんてわからんしね

>>430
機能がOKだと証明するわけではない
「テスト項目の通り実行したらこの通りの画面になった」
つまり、テストを行ったという事を証明しているにすぎない
だから入力ミスや、テスト実行者の勘違いまではフォローしきれない

機能の証明ではなくテスト実行の証明だから
わざわざエビデンスに日時が入るように撮影することを要件としている

機能がOKだという証明だけであれば日時は不要だろう
実際、自動テストはテスト実行日時など重視していないはずだ
（デバッグの為に日時を保存しているにすぎない）

エビデンスに日時を入れるという行為があるかどうか
それだけでもテストの性格がわかるというものだ

テスト実行者を信用しないのであれば自動テストで十分だろう

自己満だろうがなんだろうが顧客が納得すりゃなんでも良い

>>431
> テスト実行者を信用しないのであれば

気にすべき所はテスト実行者を信用するかどうかじゃなくて
ミスなくテストしたかどうかでは？
信用できる人にだって間違えることはあるんだし

テストのテストを作ろう

画面にせっせと入力して保存ボタン
データベースに登録されてるかチェック

苦しい_(┐「ε:)_

>エビデンスに日時が入るように撮影することを要件としている

初めて聞いたわw
日付入れたところで改ざん可能なんだから日単位でファイルを上げて
履歴追えるようにしとけば十分だろ

>>436
ログの位置がわかりやすいようにってだけだろそこ

xUnit嫌いな人割と身近にいるわ
単体テストしない派というか

>>438
仕様が決まってるテストはいいが決まっていなかったり曖昧なのは滅茶苦茶時間がかかるので嫌い

>>439
は？
テスト仕様を決めるのも仕事だろ

テスターのな

>>441
テスターがどんな仕様を決めたの？

テスターが仕様決めるって意味わからんｗ
この関数は引数の全ての値を足す関数だ
って決めるんか？ｗ

俺は常に自分でテストコードを書きながら仕事をしているから、いまいち単体テスト専用のテスターという存在がよくわからん。

新人教育目的で自分の成果物に対して不足しているテストコードを修正する形で書かせることはあるけど、基本的には実装する時にはテスト仕様もできてるしなぁ...。

>>444
用語を知らないから、単体テスト＝1画面のテストとか1アプリのテスト思ってるやつが居るんだよｗ
単体のexeファイルをテストするのが単体テスト

はぁ～～～～ばか～～～

小さい関数を心がければテストコードが必要なほど複雑なコードって書かなくない？
テストコードを書くと必ずデータ用意しなきゃならないけどそのデータを間違って入力する確率のほうが高い

>>445
俺さ、まさにリアルタイムでスマホアプリ開発しててテストコードを書いてるんだけど、お前、頭大丈夫？

iOS、android、Windows対応のアプリ作ってるけど、こんなこと言う奴初めてみたよ。
JavaとかでJUnitとか聞いたことない？
C#でプロジェクトファイルを作るとき、Unit testというテンプレート見たことない？

お前、Windows開発すらしたことないだろ。
俺は別に1画面がどうのこうの言ってないし、そもそもexe単体とか論外だわ。

まず、単体テストについてググれカス。

>>447
日本語圏内で言う単位テストは普通は画面、帳票、バッチ、ようは要件定義に書いた機能ごとのテストだよ

xUnitとかJUnitのようなもののことを言いたい場合には、ユニットテスト、あるいは自動テストと言ったほうがいい
日本ではユニットテスト≠単位テスト

1からのやり取りを見てもそんなこと言えるの？
あと、ググるとまっさきに出るのが「単体（ユニットテスト）とは」なのだが。
そして、俺もその認識なのだが。

>>447
おまえは文章が読めないんだなｗ
おまえも馬鹿の一人だわｗ

>>446
どれだけ小さい関数を作っても、テスト担当者にテスト仕様書を書いてもらないわないと
自分じゃ、テストできないアホがいる。
ログに出力してそれっぽい値ならOKとかいってるアホがいる

>>450
そういうことか！
うん、俺も馬鹿だったわ。
いや、本当にすまぬ...すまぬ。

>>448
うちの会社もそれだなー

ん？割とガチで単体テストを機能毎のテストとして扱う会社は多いのか？

基本情報技術者試験や応用情報技術者試験の単体テストに関わる問題とか見ると、明らかにユニットテストの意味の問題があるように見えるのだが...。

そうなると、自動化もクソも無くね？
それ以前に、>>448の言うことは本当なのか気になる。
本当なら>>448の言う単体テストについて紹介している文献とかあると思うのだが...ソースがほしい。

>>454
大企業で仕事したらわかるよ
だからエビデンス取るんやで

>>455
まず、ユニットテストと単体テストを区別するというのが本当なのか怪しいが、区別しているのなら、もちろん、そのユニットテストもやってるよね？

更に聞くと、このスレはあなたが方の言う単体テストとユニットテスト...どっちについて扱うスレだと思う？

テストの分類と自動化するしなは別のベクトルだ
単体テストといったら自動化と連想するのはそのあたりの区別がついてないのだろうな
役割の分割をしないでGODクラス作ってそうなタイプ

>>456
やってないよ！

>>457
手動で行ってエビデンス取るって言ってるんだからユニットテストでないことは明らかだと思う

このスレでユニットテストの話をしてる人は社会経験のない木偶の坊だと思ってる

まぁ、責務が曖昧なGodクラスのユニットテストなんて自動化しようがないからな。
些細な変更ですぐに仕様が変わるし。

ユニットテストで不合格になるのではなく、
ユニットテストができないから不合格になるパターンだな。

でも、恐ろしい事を思いついてしまったよ。
もしも、常に神クラスを書いていてユニットテストができない企業がいたとする。
そして、その企業があまりにもユニットテストができないからユニットテストの意味を曲解することにしていたとしたら...やばいね。

まぁ、いいや。仕事だ。しばらく席を離れるよ。