T-SQLをどのように単体テストしますか
T-SQLをどのように単体テストしますか？どのライブラリ/ツールを使用していますか？
コードの何パーセントが単体テストでカバーされており、どのように測定しますか？最初にユニットテストするモジュールをどのように決定しますか？
ユニットテストハーネスに投資した時間と労力は報われたと思いますか？
ユニットテストを使用しない場合、その理由を説明できますか？
T-SQLをどのように単体テストしますか？どのライブラリ/ツールを使用していますか？
これを見てください TSQLUnit そしてこれ tSQLt 。
私は、junitやnunitなどのT-SQLをテストするために、多くの言語でいくつかの異なるフレームワークを使用して実験しました。私がこのルートを選んだ理由は、これらの他の言語の豊富なテスト環境を利用するためでした。たとえば、nunitを使用する場合、テストのステータスを確認するための優れたコマンドラインとGUIビューアがあり、.netを使用してテストを作成するため、SQLサーバーに非常に簡単に接続できます。 JUnitは、NetBeansやIDEなどの多くの商用およびオープンソースのIDEA環境との優れた統合を備えており、T-SQLテストをJavaコードテストのようにしています。 、非常に豊富です。ネガティブな点は、T-SQLを作成しているだけでなく、T-SQLをテストするためにJavaまたは.netも作成していることです。
また、Rake（makeまたはantのようなもの）でRubyを使用し、sqlcmdをシステムコールして実行したsqlスクリプトを実行しました。スクリプトは、値と文字列をRubyに返し、テストに合格または不合格にします。このアプローチは非常に無駄がなく、他の人が簡単に理解できるので、私はこのアプローチが一番好きでした。上記の他のルートでは、開発者は.netまたはJavaを使用する必要がありました。これは、すべてのDBAタイプがある場合、SQLスクリプトを使用したRubyのアプローチが私の方から販売しやすい場合に克服するのが難しい場合があります。経験。 DBAタイプはオープンで、言語のようなスクリプトを簡単に取得できる傾向があり、Rubyは学習曲線が低く、スクリプトは.netまたはJavaクラスに比べて簡単に実行できます。
コードの何パーセントが単体テストでカバーされ、どのように測定しますか？
ほとんどのデータベースシステムは、作成時にテストが作成されていなかったため、おそらく20％しかありません。そのため、新しい欠陥や機能拡張が発生したときに、テストを積極的に追加し、テストを追加しています。
ユニットテストハーネスに投資した時間と労力は報われたと思いますか？
データベースは、ほとんどの企業の基本です。私の意見では、それは常に報われます。あなたのビジネスが顧客のがらくたと高い失敗率を許容するなら、それは自由に行うことができないので、テストはおそらくそれの価値がありません。
ユニットテストを使用しない場合、その理由を説明できますか？
誰かがこれに対する不条理ではない答えを思い付くかどうかを見たいと思います。ちょっと、道を運転するときに子供をチャイルドシートに入れてみませんか...「費用がかかりすぎる」...「子供を乗せるのに時間がかかりすぎる」..「彼はそれがなくても安全です".."それを正当化するために何がうまくいかない可能性があるか ".."時間が足りないだけです "これらはすべてbsです。
ええ、私は少し極端なことを知っているかもしれませんが、実際にシステムがあり、それが会社の価値をもたらす場合は、本番の問題になる前にいくつかの問題をキャッチするのに役立つように統合テストする必要があります。ユニットテストは万能薬ではありませんが、できる限り最善を尽くさなければならないツールの1つです。
全体として、構造化テストに関しては、ほとんどの人がデータベースにフリーパスを与えていると思います。なぜなのかわかりませんが、会社ごとに見てきました。その変化を見てみたいです。
ユニットテストツールの場合、私は DBFit で最も成功しました。
TSQLテストカバレッジを測定するツールを見つけたことがありません。
テストの設定にはある程度の苦痛があることを認めた後、プロジェクトが些細なレベルの複雑さに達すると、単体テストによってコードの品質を向上させることができることがわかりました。
通常のコードと同様に、T-SQLの一部の項目は他の項目とは異なる方法でテストする必要があります。多くの静的なもの（トリガーやビューなど）をコード生成する場合、通常、テストの負荷は軽くなります。
私たちの特定のシステムは、ほぼ完全にT-SQLでコーディングされています。
T-SQLをどのように単体テストしますか？どのライブラリ/ツールを使用しますか？
比較する良い結果がわかっています。毎月の分析実行では、月ごとに比較し、実行時に実行して、コードとデータの変更の影響を理解します。私たちの主なツールは、2つのテーブル/ビュー/サブセットを比較し、違いを特定するストアドプロシージャです（しきい値オプションを使用）。
コードの何パーセントが単体テストでカバーされ、どのように測定しますか？
ほとんどのプロセスで生成されたデータを、過去の動作に対して検証します。ビジネス要件に応じてコードを変更する場合、両方の実行からの出力を比較して影響分析が実行されます。また、例外レポートに大きく依存して、データが期待値/構成に準拠していない場合（可能な場合はスキーマの制約）を事前に判断します。
ユニットテストハーネスに投資した時間と労力は報われたと思いますか？
はい
ユニットテストを使用しない場合、その理由を説明できますか？
私たちのユニットテストは、私たちの「プロセス」レベルのそれぞれで行われます。通常、各プロセスは単一のストアドプロシージャに対応しているため、これがテストするユニットです。最終出力の比較は、システムテストに対応します。
T-SQLをどのように単体テストしますか？どのライブラリ/ツールを使用していますか？
tSQLt 100％
コードの何パーセントが単体テストでカバーされており、どのように測定しますか？最初にユニットテストするモジュールをどのように決定しますか？
一部のプロジェクトは100％、ほとんどはそれ以下です:)
私は、redgateが後援し、SQLテスト製品に含まれているT-SQLコードカバレッジツールを作成しました。
https://github.com/GoEddie/SQLCover
ユニットテストハーネスに投資した時間と労力は報われたと思いますか？
はい100％、私がテストを受けるたびに、それは私たちがより速く動くのを助けました。テストがなかったときはいつも、それは私たちを遅くしました。
ユニットテストを使用しない場合、その理由を説明できますか？
人々が自分のコードをユニットテストしないのは説明できないと思います:)
最近、T-SQLユニットからVisual Studio2010ユニットテストフレームワークに切り替えました。最大の不満は、次のテストのためにデータベースを「クリーン」なままにするために、テスト内で独自のトランザクションスコープを管理する必要があることです。これは、T-SQLユニットが最初に提供するものです。
私たちの目標は、ストアドプロシージャを100％カバーすることです。これにより、開発と完全に連携しなくても、必要に応じて基になるテーブル構造と関係を変更できます（独立したデータチームと開発チームがあります）。テストカバレッジの測定はまだ開始していません。現在、このテクノロジースタックを使用して最初の本番展開を開発中です。私たちにとって、アプリケーションとデータ間のインターフェイスはストアドプロシージャです。まず、アプリケーションチームのニーズを満たすのに十分なストアドプロシージャを構築し、継続的インテグレーションを実現するのに十分な署名が安定したら、単体テストを構築します。 TDDをやりたかったのですが、それを現実的な選択肢にしない期限があります。
テストハーネスのROIは測定していませんが、経験から、本番データベースへの変更には非常にコストがかかることがわかっています。