プレゼンテーションの自動化されたテストのコーディングをすぐに開始します。 WatiN および Selenium を推奨しているようです。 ASP.NET Webフォームの自動テストにどちらを好みますか?これらの製品のどれがあなたのためによりよく働きますか?
補足として、私はWatiN 2.0が2008年3月からCTPになっていることに気付きました。
私は現在、2009年の第1四半期にWatiN 2.0のベータリリースに取り組んでいます。これは、現在のCTP 2.0バージョンへのメジャーアップグレードであり、基本的にFireFoxとIEバージョン1.3.0はIEの自動化を提供します。
心配ありません。
これがあなたの選択に役立つことを願っていますJeroen van Menen主任開発者WatiN
コミュニティによって引き続き改善およびサポートされるフレームワークに深刻な長期投資を行うことを検討している場合は、おそらくSeleniumが最善の策です。たとえば、Matt Raibleのブログでこの情報に出会いました。
金曜日の時点で、Googleには50を超えるチームが社内のSelenium Farmで1日あたり51K以上のテストを実施しています。これらのテストの96%は、Selenium RCおよびFarmマシンによって正しく処理されます。他の4%はRCバグが原因で、一部はテストエラーが原因ですが、原因を特定することは困難です。 Seleniumは、Google内のWebアプリケーションの機能テストの主要なテクノロジーとして採用されています。それは朗報です。
また、最近、Seleniumのミートアップの1つに行って、GoogleがSeleniumの改善と、Simon Stewartによって開発された自動テストツールであるWebDriverとの統合に深刻なリソースを投入していることを知りました。 WebDriverの主な利点の1つは、ブラウザー内でJavascriptアプリケーションとして実行するのではなく、ブラウザー自体を制御することです。つまり、「同じオリジン」問題のような大きな障害はもはや問題になりません。
両方をテストし、WaTiNを使用することにしました。他の人が指摘しているように、SeleniumにはWaTiNにはない素敵な機能がいくつかありますが、Seleniumが動作する問題に遭遇しました。正しく覚えていれば、私たちが遭遇したセットアップの問題は、SeleniumがWaTiNがすべての処理を行っていた実際のブラウザーを制御するための個別のアプリを持っているという事実に起因していました。
私は両方試してみましたが、ここに私の最初の考えがあります...
WatiN
いいもの
悪い人
スクリプトの例(C#)。あなたはSeleniumではこれを行うことができません(少なくとも私が知っていることではありません):
class IEManager
{
IE _ie = null;
object _lock = new object();
IE GetInstance(string UrlFragment)
{
lock (_lock)
{
if (_ie == null)
{
var instances = new IECollection(true); //Find all existing IE instances
var match = instances.FirstOrDefault(ie=>ie.Url.Contains(UrlFragment));
_ie = match ?? new IE();
if (match==null) //we created a new instance, so we should clean it up when done!
_ie.AutoClose = true;
}
}
return _ie;
}
}
セレン
すべてにもかかわらず、私は最後にWatiNを使いました。私は主に小さなスクリーンスクレイピングアプリケーションを作成し、開発にLINQPadを使用したいと考えています。リモートへの接続IEインスタンス(私は自分で生成しなかったもの)は大きなプラスです。既存のインスタンスをいじることができます...その後、少しスクリプトを実行します...再びフィドルなど。これはSeleniumで行うのが難しいですが、「一時停止」をスクリプトに埋め込むことができ、その間にブラウザを直接いじることができると思います。
最大の違いは、Seleniumがさまざまなブラウザをサポートしていることです(IEまたはFFだけでなく、 http://seleniumhq.org/about/platforms.html#browsers を参照してください。
また、Seleniumにはリモートコントロールサーバー( http://seleniumhq.org/projects/remote-control/ )があります。つまり、テストと同じマシンでブラウザーを実行する必要はありません。コードが実行されています。したがって、Webアプリをテストできます。異なるOSプラットフォーム上。
一般に、Seleniumの使用をお勧めします。私は数年前にWatiNを使用しましたが、その安定性には満足していませんでした(おそらく今では改善されています)。私にとってSeleniumの最大のプラスは、Webアプリをテストできるという事実です。異なるブラウザで。
どちらでもない。 Coypuを使用します。 Seleniumをラップします。はるかに耐久性。 https://github.com/featurist/coyp
更新そうだ、オリバー、あなたは正しい。 Okなぜそれが優れているのでしょうか?個人的には、IEは非常に壊れやすい-多くの「標準」ドライバ例外があります。 ajaxの重いWebサイトで単体テスト用のSeleniumを使用しているときに、また時間を見つけました。
テストプロジェクトとしてc#でスクリプトを書きたいと言ったのですか?はい連続ビルド展開内の受け入れテスト。
まあCoypuは上記を扱っています。これは、Seleniumのラッパーであり、次のようなテストフィクスチャを許可します。
browser.Visit("file:///C:/users/adiel/localstuff.htm")
browser.Select("toyota").From("make");
browser.ClickButton("Search");
...(設定可能なブランドの)ブラウザを起動し、スクリプトを実行します。範囲指定されたリージョンでうまく機能し、非常に拡張可能です。
GitHubにはさらに多くの例がありますが、以下のOlvierが言及しているように、Adrianのビデオは素晴らしいです。 .Netの世界でブラウザベースのテストを実行する最良の方法だと思い、それをRuby namesake capybara
私は両方を使用しましたが、両方ともうまくいくようです。私のうなずきはSeleniumに対するもので、Ajaxのサポートが優れているように見えました。私はWaTiNが成熟したと信じていますが、前回使ったので同じものが必要です。
最大のことは、どの開発環境に参加したいですか? SeleniumとWatinにはレコーダーがありますが、Seleniumはブラウザーにあり、watinはvisual studioにあります。 +と-はそれらの両方です。
これまで、私たちは企業向けのソリューションを提供するための純粋なマイクロソフトショップであり、WatiNを採用しました。これは将来変更される可能性があります。
より最近のソースとして:
Microsoftは MSDN Magazine 12/201 SpecFlowとWatiN(クールなBDD-Behavior Driven Development)を組み合わせたBDD-Primerを印刷しました。著者のBrandon Satrom(msft Developer Evangelist)も2010年12月に Video Webcast 上記の調査結果を1:1で詳細に教えています。
Christian Hassa のSpecLog、SpecFlow、およびTeam Foundation Server(Acceptance Test Driven Development/Behavior Driven Development)を使用したATDD/BDDのサポートに関する2011年4月の Whitepaper があります。チームがSpecFlowを構築しました。
私はWatinを使用していますが、Seleniumは使用していません。私はすぐにWatinを立ち上げて実行し、ほとんど問題がなかったと言うことができます。私がやりたかったことは考えられませんでした。 HTH
私は通常、Seleniumを使用します。これは主に、テストの開始点を記録するためにFireFoxのSelenium IDEプラグインが好きだからです。
WebAii をお勧めします。これが私が成功した理由であり、それを使用するとき、私の不満はほとんどなかったからです。 Seleniumを試したことは一度もありませんでしたが、WaTiNを使用したことはあまり覚えていません。少なくとも、正常に機能するようになるまでは。 WebAiiには独自のダイアログハンドラを実装するためのインターフェイスがありますが、Windowsダイアログを適切に処理するフレームワークは知りません。
両方の使用を検討しました。 Seleniumのレコーダーを使用して、FFでいくつかのテストを作成しました。 Watinでも同じことをしようとしましたが、Watin Recorder(2.0.9.1228)はサイトにとってまったく価値がないです。 IE6でサイトをレンダリングしているように見えたため、私たちのサイトは事実上記録できなくなりました。 IE6はサポートしていません。使用しているブラウザを変更する方法が見つかりませんでした。ワティンレコーダーは1台しか見つかりませんでした。複数ある場合、または最新のものがあれば、コメントしてください。
Selenium Recorder IDEは使いやすく、テストをC#に移植します。これは素晴らしいことではありません。ブログ投稿を読んでも、そのため、生成されたコードを少し操作する必要がありますが、それでも90%動作し、他の方法よりも優れています。
私のお金/時間のために、セレンは新しいテストを簡単に構築できるという点で優れています。 IEにはFirebugと同等の優れた開発者ツールバーはありません。そのため、Firefoxで開発を始めています。 Firefoxで正常に動作するレコーダーは大きなボーナスです。
ここでの私の結論は、チャーチルによる民主主義の引用によく似ていました。セレンは、自動化されたUIテストの最悪の形です。他のすべてを除く
Iframe、モーダルダイアログ、およびクロスドメインiframeにアクセスする必要がある場合は、WatiNが最適です。 Seleniumはcommandtimeout例外をスローしていたiframeを処理できませんでした。 WatiNでは、特にWebサイトでIE ShowModalDialogなどの特定のものを使用している場合、さらに多くのことができます。WatiNはそれらすべてを非常にうまく処理します。クロスドメインiframeアクセスもできます。
接線を離れる危険があるので、Axe/WatiNをお勧めします。 Axは、基礎となるテスト「言語」を知らなくても、「手動」テスターによってExcelでテストを作成できます。オーダーメイドのアクションを作成するには「技術者」が必要です(IE。今日はやや複雑なテーブル検索と相互参照を行う必要がありました)。
また、UK Government Gatewayプロジェクト(6K +テストの自動テストがあると思います)が最近、すべてのテストを1週間以内にAxe/WinrunnerからAxe/Watinに移植したと聞きました!そして、テストの多くは非常に複雑です-数年前に取り組んでいたので...
潜在的なクライアントが使用しているため、私は現時点でSeleniumを見ています。しかし、私はAxeを「仕事の馬」ツールの上のレイヤーとして簡単に見ることをお勧めします。