2009-04-23 6 views
7

私は大量のNUnitテストを行っています。私は与えられた実行から結果をデータベースにインポートし、結果のセットを特徴付け、それらをユーザに提示する必要があります(テスト失敗のための電子メール、結果を調べるためのウェブプレゼンテーション)。私は時間の経過とともに複数のランを追跡する必要があります(時間の経過とともに障害率を報告するなど)。NUnit結果をインポートするためのデータベース?

XMLは、nunit-consoleによって生成されたXMLになります。私は最小限の騒ぎでXMLをいくつかのデータベースにインポートし、その結果を保存して提示することができます。同様に並べ替えることができるようにするために必要な多数のカスタムカテゴリが用意されています。

個人のニーズに合わせてカスタマイズできるこのタイプのデータのインポートを処理できるデータベーススキーマを知っている人はいますか?このタイプの問題は共通しているように思えるので、共通の解決策が存在するはずですが、見つけられないようです。誰もが以前にそのような解決策を実装していれば、アドバイスも高く評価されます。

+0

あなたの顧客/ステークホルダーがnunitの結果を利用して、あなたの特徴(スペック)が成立していると主張する場合。あなたは行動主導の開発に目を向けるべきです。これらのフレームワークは、読みやすい形式で結果を提供します。 http://en.wikipedia.org/wiki/Behavior_Driven_Development – mxmissile

答えて

4

CruiseControl.NETTeamCityなどのビルドサーバーの後に実際にいるように聞こえます。

テストを実行するビルドサーバーを入手し、失敗したものと失敗したものを伝える作業を行います。

私はTeamCityをセットアップすることが何桁も簡単であることをお勧めします。

+0

Build Serverには大したことはありません。それは正解かもしれませんが、直接結果を扱うよりも、必ずしも常にまたは明らかに優れているとは限りません。私たちはTeamCityの予算を持っていません(私は上司にやり始めていると思いますが).CuriseControl.Netは、ビルドのために現在行っている作業にはうまく適合しません。私はちょうどNUnitとデータベースを使用してソリューションに興味があります。 –

+0

無料のソフトウェアの予算をお持ちでないのはなぜですか? TeamCity Professionalには何の費用もかかりません。 –

+0

TeamCityは、かなり簡単なプロジェクトに取り組んでいる小規模チームにとっては無料です(Beerのように)。私たちはどちらも持っていない。 –

2

私はここで同じ問題を解決しようとしています。現在、XML結果を挿入ステートメントに変換するためのXSLTの作成に傾注しています。次に、コマンド行のSQLインタープリターを使用して、結果として得られるinsert文のファイルを実行します。理想的には、私はむしろこれのすべてを処理するNUnitアドイン/エクステンションを持っています。残念ながら、私は1つを見つけることができませんでした。

1

IainMHの答えを構築するには、BITTENでTracを使用してみることをお勧めします。これはオープンソースのビルドシステムで、nユニットテストを実行して結果を報告することができます。私は現在、その正確な機能のためにそれを使用しています。

1

MS SQLを使用する場合、すべてのXMLを[xml]データ型の共通列にインポートできます。このとき、xpaths、検索および変換を行うことができる。

1

現金で縛られている場合、CruiseControlまたはTeamCityの別の代替手段はAtlassians Bambooです。私はそれが使いやすさのために彼らのソフトウェアの巨大なファンであり、彼らはあなたが10ドルのために竹を得ることができる場所で取引を持っています。

-3

なぜ結果をデータベースに保存する必要がありますか?誰がそれらを使用する予定ですか?失敗の数は大きくすることはできません。それが(繰り返し)開発プロセスが間違っている場合。プロセスを修正します。廃棄物(無駄のない原則の1つ)を取り除き、収集しないでください。

小さなステップ(反復回数を減らし、連続ビルド)を行い、依存関係を解消します。

これは一般的ではありません。この種の問題を抱えるプロジェクトは配信されずにキャンセルされます(結局)。

[編集]マイケルは、nunitの失敗をより長い時間にわたって追跡することでゼロの値を提供します。短いフィードバックループが必要です。今すぐ問題を修正してください。あなたが多くの問題を蓄積するまで待っていれば、あなたは騒音に圧倒されるでしょう。

良い問題追跡は、右(最高可能な抽象化)レベルで行われます。間違いなく単体テスト。

+1

問題の根本原因を特定するために何が失敗するか(およびいつ、どのくらいの頻度で)かが重要です。それがなければ間違ったプロセスの問題を解決しようと時間を無駄にします。私は良い問題のトラッキングは、希薄な開発プロセスの_臨界であると言うでしょう。マイケル、正確に –

+0

。非常に不十分なテストセットを持つレガシーコードベースに苦しんでいます。私たちがどのようなテストをしているか(それは多数ありますが、不完全なカバレッジを提供します)は、結果にある程度の矛盾があります。長期間(数ヶ月)にわたって不一致を追跡することは、優先順位付けにとって重要です。 –

+0

私は原則として合意していますが、私たちの場合でも1日の失敗の分析は多くの洞察を提供することができます。私たちのソフトウェアが当社のハードウェアとどのように相互作用するかをテストします。カラーセンサーでのみ障害が発生した場合は、どこで問題を探すのかがわかります。それが高解像度の白黒センサーでのみ発生する場合は、他の場所を見ます。私たちのセンサには、重要であるかもしれない(またはそうでないかもしれない)ダースのプロパティがあります。 XMLの結果を分析するのは難しいことです。私は無駄を排除しようとしています。 –

1

これを避けることを望みましたが、NUnit結果XMLスキーマからデータベーススキーマを生成しました。しかし、NUnitはいくつかの(不正確で奇妙な)重要な統計情報(「無視された」対「実行されない」など)を決定する処理を行うため、少し不足しています。

まだ完全なCITビルドシステムではないスキーマ/プロセスを見つけることが期待されていますが、結果をインポートするためにデータベースをカスタマイズすることができますが、現在我々は、必要なレポートを取得するために多くのカスタマイズを行う必要があります。

+0

あなたはこれまでのことを分かち合いたいですか?私はこれに戻り、NUnitに加えて個人的にそれを取ることを検討しています。 –

関連する問題