PostgreSQL Part.11©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>268
・普通のプログラムでは簡単に書ける「共通処理」が書きづらい
→ まぁ、functionで実装していけばいいが、以下の考慮が必要になる
・テストを変更するのにいちいちmigrationが必要
・テストはテスト対象と同一データベース内におく必要がある
・故に、CIでテストしようとすると全員のテストを一つのDBに入れる必要がある
・そうすると、他人とシンボル名が重複しないようにするなどの配慮が必要だとわかる
・スキーマで分割すればいいじゃんとか思う
・グダる
普通にコードで書くのが楽よ >>269
コードって別の言語だし、ユーザー、スキーマは結合テストレベルでは本番環境に無理に合わせない。
なんでいきなりシステムテストレベルで確認しようとするのか?
まあ小さいパッケージやWebサイト屋だとそういうテストをする会社や人間が存在するのは知っているが。 >>270
ちょっと言ってる意味がわからない。
例えばトリガーを単発でテストする方法は>>261に書いたとおり。
ユニットテストレベルの話をしてるのだが。 >>270
数千人月以上のメガプロジェクトの五次請けさん、お疲れっす pl/pgsqlの、お勧めの入門書ってありますか?
ネットである程度調べられるけど、できれば体系的に学びたいのので >>272
いろいろあなたがずさんなのはいいけど、回答するような立場ではないことは自覚した方がいい。 >>276
>>270の方が回答するレベルでも立場でもないわなぁ
あと、>>270のいうシステムテストレベルって何だよ? コード書けないし、>>261レベルのコードでも何やってるかわかんなくてぐだぐだいってるんだろ >>279
最近のレスでは、君が一番ピントずれてるよ 結局、どうやってテストするかって>>261以外誰も示せてないな >>279
で、君のところではどうやってテストしてるの? あれかな、Excelの定型処理を自動化しようとしてマクロ書いたら怒られた的な話? つか、SIerが仕切る大規模開発で、トリガーが許されるケースなんかあるのか?
トリガーはおろか、ストアドすら許されたことがないんだが。 >>284
そのシステム開発プロジェクトのポリシーだろうけど、理由の一つはプロジェクトメンバーのレベルがあらゆる面で低い、もう一つはデータベースがよくわからなくて上がトリガやストアドファンクションを禁止しているパターン。
こういうそれなりに大きいプロジェクトは総じてクソでうまくいかない。 >>282
データとSQLを用意してトリガーを動かして実行前と実行後を比較する。
なんでこんなあたりまえのことを言われなきゃわからないのか? >>285
最も大きい理由は、大抵データベース設計チームが独立していて、そこが物理設計まで行い、
パフォーマンスの責任まで負うから。
次に大きい理由は、スキーマの変更手順が決まっていて、製造工程中に変更とか無理だから。
その次は、大抵大きなプロジェクトでは、データベースをデータストアとしてしか使わないから。 >>286
> データとSQLを用意してトリガーを動かして実行前と実行後を比較する。
それマニュアルでやるの大変でしょ?
>>261みたいにテスト書いとけば、CI/CDにも組み込めるよ。
別にマニュアルでやるのは否定しないが、だからといって>>261を否定するのはおかしいよ。 >>286
それ、>>237と同じじゃんw
>>237を否定してたように見えたが、そうじゃないなら何と戦ってるの? クエリを発行する手段としてホストコードを使うよ、
単体テストレベルの話ならユニットテストツールも使えるよってだけなんだけど、
> 何かの言語と結合して
> コードって別の言語だし
というメンタリティの持ち主なので、話が全然噛み合わない >>290
あなたみたいにこういうのがテストだと思っているから話がおかしくなる。
単にデータベースを使いこなせないことをごまかすために言っているとしか思えない。 PostgreSQLは使われ方から細かいテストをする習慣のない人間が使っていることが多いから理解できないのもわかるよ。 >>291
手動じゃないなら、具体的にどうやってるの? 手動じゃないならなんらかの方法で結果を自動チェックしてるわけで、>>261と何が違うんだってことになる >>295
それだと結合テストの部類だろ。少なくともPostgresqlなんだからPostgresqlで完結しろよ。 もしかして手動でSQL実行してトリガが自動で動くから自動って言ってるの?w
まさかそんなわけないか >>298
自動テストの「自動」を誤解している。
よくいるのが有名自動テストツールを使用するのが自動テストで、それで確認できるテストだけがテストだと思ってる人間。
画面をポチポチやるのはたしかに手動だが、それ以外は昔からスクリプトでテストする。
あまり自動化しすぎるとテストにならなくなる。すでに完成しているシステムのリグレッションテストなら有効。
リファクタリングもそうだが特定のツールの機能を使うことを指している人間も多い。
話を戻すとここまでpsqlもPL/pgSQLも出てこない。PostgreSQLやMySQLは入門書で他の言語から使うことばかり書かれているから仕方ないとは思う。
データベースはデータの入れ物、SQLはあまりテストしない習慣の人間といくら話しても平行線をたどる。
LAMP環境だとエンタープライズの感覚がわからないひとは多い。 好意的に見れば全体的にさほどおかしな理解はしてないようだけど
一つのレスにあれもこれも詰め込みすぎて結局何を言いたいのかさっぱり分からない
知識をドヤりたいんだったらむしろ出し惜しみした方がいいよ >>301
だからいままでまともにレスしてないんだけど? >>301
あんたも知らないなら俺にかまうなよ。2chレスが気になって仕方ない病か? >>299
> よくいるのが有名自動テストツールを使用するのが自動テストで、それで確認できるテストだけがテストだと思ってる人間。
そんな奴はまれだろ
> リファクタリングもそうだが特定のツールの機能を使うことを指している人間も多い。
そんな奴はまれだろ
> SQLはあまりテストしない習慣の人間といくら話しても平行線をたどる。
自分が頓珍漢だから平行線になっている可能性
> LAMP環境だとエンタープライズの感覚がわからないひとは多い。
PostgreSQLスレでそんなこといわれてもね トリガーを発火させるためにコードを書いたら発狂する人がいるということはわかった w スクリプトってSQLとは別の言語じゃないんですかね >>308
あおりじゃなくて素直に聞きたいんですが、SQLスクリプトで>>261のようなテストはどう書くんですか? >>309
SELECT、INSERT、SELECTでいいでしょう。 >>310
それは、テストがOKだったかどうかは目視で行うってことですか? >>299
> 画面をポチポチやるのはたしかに手動だが、それ以外は昔からスクリプトでテストする。
その昔がいつのことかわからないけど、
DbUnitは2002年から http://dbunit.sourceforge.net/
SQLUnitは2003年から https://www.openhub.net/p/sqlunit
PlSqlUnitは2003年から http://wiki.c2.com/?PlSqlUnit
存在してるよ。 まさか、
----
select user_count from ...;
insert into users values (...);
select user_count from ...;
----
を実行しますってことじゃないよな? >>312
そういうのを使うのがテストかどうかは何をもってよしとするかだろ。
それも結局、単体テストになってねえし。 いい加減な外国人が作ったもの、やってることが正しいわけではない。青臭いのばかりわいてくるなw テストのやり方を知らないから、テスト嫌いなアメリカ人がテストのために作ったものを使うのがテストだと思ってるんだろうな。
テストは泥臭いのも大事。 >>318
カウントじゃなきゃいいだろってことの裏返しでいいんだろか >>318
> それカウントはおかしいだろw
どこがだよ?
いい加減、どうやってテストするのかちゃんと書けよ。
書けないのか? まぁ、PostgreSQLもMySQLもOracleもSQL Serverも外国人が作ったんですけどね。 マニュアルでテストしていたのをコードで書くと、テストではなくなってしまうという不思議 >>317
> テストは泥臭いのも大事。
スマートにできる所はスマートにやればいいだけのこと >>315
> そういうのを使うのがテストかどうかは何をもってよしとするかだろ。
いや、どう考えてもテストでしょ。
テストじゃなければ、何なんだ? ヘッドレスブラウザを使った、コードによるE2Eテストはテストではない IDENTIFICATION DIVISION.
なつかしいなw まさかこんなスレにまでコボラーが紛れ込んでいたとは
油断も隙もねえなゴキブリ野郎だなコボラーってやつは 若気のいたりだろうけど謙虚さがなさすぎだな。結局、教えてくれが本音なのに批判だけして正当化してるだけだろw >>330
お前のテストのやり方なんて、誰も知りたくないだろ >>330
ID:hwqbFp3vに対するコメント?
若気というよりじじい臭がすごいんだが >>331
いろいろ考えがあって正解はない。ただデータベースならデータ重視のテストをすべきで、特にデータ型はみてもらいたい。 >>333
だから、どうやってテストしてるのか、はよ書け >>332
ポスグレでテストは適当でいいはむしろ昔のWebサイトの感覚を引きずっているおっさんの考え方。せっかくポスグレが他のRDBMSに対向すべく機能を追加してるのにまともな使い方を広める人間がいないからシェアが落ちてしまった。 >>334
なぜデータベースの最初のテストを別のプログラミング言語でテストしてはいけない理由がいまだにわからないのか? >>336
そんなのいいから、お前のテスト方法はよ書け そろそろ小出しにするのやめてまるっとさらけ出しちゃえばいいのに
一斉に叩かれそうだけど賛同者が現われる可能性もないわけじゃないじゃんw ぽすとぐれすきゅーえる
ぽすとぐれすえすきゅーえる たぶんアメリカ人もポストグレスキューエルと言ってないよな。言いにくいだけ。 >>339
どうせ>>313みたいなクエリ実行して、目視で確認だろ >>346
エビデンスを目視で確認だろw
なんなのかさっぱりわからん。 >>347
エビデンスというのが>>313の出力結果だとしたら、それがテストOKなのかどうかが第三者にはわからない
まあ、別途テスト仕様書的なものを書けばいいけど
--
No: 123
ケース: ユーザを追加するとユーザ数がカウントアップされる
テスト方法:
1. 現在のユーザ数を取得する
select user_count from ...
2. ユーザを追加する
insert into users values (...)
3. 現在のユーザ数を取得し、1.で取得した数+1になっていることを確認する
select user_count from ...
-- 別人が断片的に言ってることを、批判したいために、自分で話を補完w >>350
いまどき上げるななんて意味もわからず、下げているんだろw このスレの最近の流れでは、ageてる奴はアホしかいない >>335
C0カバレッジ100%を目指せって話をしてるのに、なんで「テストは適当でいい」とかいう話にするのかわけわからん >>353
そのテスト基準をなぜDBにあてこもうとするのか? データ観点ではなくてロジックの網羅テストがなぜここで出てくるのか。 >>354
話の流れ的に、トリガーやファンクションをテストする場合の話な
C0カバレッジ100%は、実行するまでエラーチェックされないからだろ
まぁ別に結合テスト(どころか運用)まで未実行の行が残ってようが、俺には関係ないけどな >>356
C0ガバレッジ100%はテストの一部にすぎないから、これが適当なテストと指摘してるんだよ。 >>357
お前どんだけ話をループさせれば気が済むんだよ
>>237
> C0カバレッジで満足できるならそこでやめる。
> 確証が持てないなら、C1カバレッジになるようなテストを追加する。
それでも不安なら、与えるデータのバリエーションを増やすとかするだろ普通
まぁ>>313レベルのテストをやってる奴にはわからないだろうけどな
お前が上でageてたアホなら、いい加減お前のテスト方法を明示しろや >>358
それがデータベースの試験にならないとなぜわからない? データ型が間違ってることに気づくのは最初のテストくらい。 >>360
最初のテストてどういう意味やで?同じテストばかり2回も3回もするんか? そりゃテスト結果によって修正入れたらまた同じテストするべ 「データ型が間違ってる」というバグを作ったことないし見たことないんだが、具体的にどういうやつなんだ? >>366
どういう意味?
create tableが間違ってたってこと? >>366
なんかよくわからんけど、それがプログラム言語でテストすると検出できないバグという訳か。 うざいやつは大抵 仕事出来ない か現場では嫌われてる。 ■ このスレッドは過去ログ倉庫に格納されています