WatiN чи селен? [зачинено]

Я скоро почну кодувати деякі автоматизовані тести нашої презентації. Здається, всі рекомендують WatiN та Selenium . Які ви віддаєте перевагу для автоматизованого тестування веб-форм ASP.NET? Який із цих продуктів краще для вас працює?

Як зауваження, я помітив, що WatiN 2.0 працює в CTP з березня 2008 року. Чи варто щось турбувати?

Просто хочу сказати, що я зараз наполегливо працюю над бета-версією WatiN 2.0 десь у 1 кварталі 2009 року. Це буде серйозне оновлення до нинішніх версій CTP 2.0 і в основному надасть вам таку ж функціональність для автоматизації FireFox та IE, як версія 1.3.0 пропонує автоматизацію IE.

Тож ніяких турбот немає.

Сподіваємось, це допоможе зробити ваш вибір Jeroen van Menen Lead dev WatiN

Якщо ви хочете зробити серйозну довгострокову інвестицію в рамки, які надалі будуть вдосконалюватися та підтримуватися громадою, Selenium - це, мабуть, найкраща ставка. Наприклад, я щойно натрапив на цю інформацію в блозі Метта Рейблі:

Станом на п’ятницю в Google працює понад 50 команд, які виконують понад 51 тис. Тестів на день на внутрішній селеній фермі. 96% цих тестів правильно виконуються машинами Selenium RC та Farm. Інші 4% частково пов'язані з помилками RC, частково - з помилками тестування, але виділити причину може бути складно. Selenium був прийнятий в якості основної технології функціонального тестування веб-додатків в Google. Це хороша новина.

Нещодавно я також пройшов один із зустрічей із селеном та дізнався, що Google вкладає серйозні ресурси для вдосконалення Selenium та інтегрує його в WebDriver, який є автоматизованим інструментом тестування, розробленим Саймоном Стюарт. Однією з головних переваг WebDriver є те, що він керує самим браузером, а не запускається всередині браузера як програми Javascript, а це означає, що основні камені спотикання на зразок проблеми "того самого походження" більше не будуть проблемою.

Ми перевірили обидва і вирішили поїхати з WaTiN. Як зазначають інші, у Selenium є деякі приємні риси, які не знайдені у WaTiN, але ми зіткнулися з проблемами, коли Selenium працює, і коли ми це зробили, це було, безумовно, повільніше при запуску тестів, ніж WaTiN. Якщо я правильно пам’ятаю, проблеми з налаштуваннями, з якими ми стикалися, випливали з того, що у Selenium був окремий додаток для керування фактичним браузером, де WaTiN робив усе в процесі.

Я намагався їх обидва, і ось мої початкові думки ...

WatiN

Добрий

• Швидке виконання.
• Інструменти створення сценаріїв - це незалежні проекти; я знаю 2: Wax (заснований на Excel, розміщений на CodePlex) та WatiN Test Record (розміщений на SourceForge). Вони не є настільки надійними, як Selenium IDE.
• Дуже хороша підтримка IE. Можна приєднувати та від'єднувати до / від запущених екземплярів. Можна отримати доступ до власних ручок вікон тощо (див. Приклад сценарію нижче).
• NuGet упакований, простий у запуску у середовищах .NET, Visual Studio та постійно оновлюється.

Поганий

• Гуглінг WatiN (watin xyz) часто змушує Google рекомендувати замість цього "watir xyz". Не так багато документації там.
• Що там мало (документація), це заплутано; наприклад: спочатку червоніє, здавалося б, немає вбудованої підтримки для селекторів CSS. Тим більше, що існують бібліотеки розширень на кшталт "WatiNCssSelectorExtensions" та багато статей у блогах про альтернативні методи (наприклад, введення jQuery / sizzle в сторінку). Під час переповнення стека я знайшов коментар Єроєна ван Менена, який підказує, що є підтримка нації. Принаймні ведучий-розробник витрачає час на переповнення стека :)
• Немає вбудованої підтримки XPath.
• Немає віддаленого виконання / на основі сітки на віддаленому виконанні.

Приклад сценарію (C #). Ви не можете цього зробити із селеном (не принаймні, що я знаю):

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 (тим більше, що треба створити новий процес).
• Вбудовані селектори CSS / підтримка XPath.
• Селен IDE хороший (не можу сказати чудово, але це найкращий у класі!).
• Відчуває більше Java-ish, ніж .NET-ish ... але насправді це мова агностики; всі команди надсилаються до "драйвера" поза процесом. Драйвер - це дійсно «хост» процес для екземпляра браузера. Вся комунікація повинна бути серіалізована в / в через межі процесу, що може пояснити проблеми швидкості відносно WatiN.
• Розв’язані процеси - "драйвер" та "управління" означають більше надійності, більшої складності тощо, але також простіше створювати сітки / розподілені тестові середовища. Мені б дуже сподобалося, якби механізм "розподілу" (тобто зв'язок між драйвером та керуванням) знаходився через WebSphere або інший існуючий, надійний менеджер черги повідомлень.
• Підтримуйте хром та інші браузери поза коробкою.

Попри все, я пішов з WatiN врешті-решт; Я, головним чином, маю намір писати невеликі програми, що знімають екран, і хочу використовувати LINQPad для розробки. Долучення до віддаленого екземпляра IE (такого, якого я не породив сам) - великий плюс. Я можу спіткнутися в існуючому екземплярі ... потім запустити трохи сценарію ... потім знову скрипнути і т. Д. Це складніше зробити з Selenium, хоча я вважаю, що "паузи" можуть бути вбудовані в сценарій, протягом якого я міг би візьміть безпосередньо з браузером.

Найбільша відмінність полягає в тому, що Selenium підтримує різні браузери (не лише IE або FF, див. Http://seleniumhq.org/about/platforms.html#browsers .

Також у Selenium є сервер віддаленого керування ( http://seleniumhq.org/projects/remote-control/ ), що означає, що вам не потрібно запускати браузер на тій же машині, на якій працює тестовий код. Тому ви можете протестувати свій веб-додаток. на різних платформах ОС.

Взагалі я б рекомендував використовувати Селен. Я використовував WatiN кілька років тому, але я не був задоволений його стабільністю (він, мабуть, покращився до цього часу). Найбільшим плюсом для Selenium для мене є той факт, що ви можете протестувати веб-додаток. у різних браузерах.

Ні. Використовуйте Coypu. Він обгортає селен. Набагато міцніше. https://github.com/featurist/coypu

Оновіть Ye Oliver ви маєте рацію. Добре, чому це краще? Особисто я виявив, що драйвер Selenium для IE, зокрема, дуже крихкий - є ряд «стандартних» винятків з драйверів, які я знову знайшов, коли керував Selenium для Unit Tests на важких веб-сайтах ajax.

Чи згадував я, що хочу написати свої сценарії в c # як тестовий проект? Так Приймання тестів у процесі розгортання безперервної збірки.

Ну Coypu займається вищезгаданим. Це обгортка для Selenium, яка дозволяє випробовувати такі світильники, як,

browser.Visit("file:///C:/users/adiel/localstuff.htm")
browser.Select("toyota").From("make");
browser.ClickButton("Search");

... що відкриє (налаштовується бренд) браузера та запустить сценарій. Він чудово підходить для областей, що охоплюють область, і ДУЖЕ розширюється.

У GitHub є більше прикладів, і як згадує Ольв'є нижче, відео Адріана є чудовим. Я думаю, що це найкращий спосіб керувати тестами на основі браузера у світі .Net та намагається слідувати за тезкою Rubycapybara

Я використовував обидва, вони, здається, працюють нормально. Я киваю на Селен, оскільки, здавалося, має кращу підтримку Ajax. Я вважаю, що WaTiN дозрів, хоча з останнього часу я використовував його, тому він повинен мати те саме.

Найбільше було б, у якому середовищі розвитку ти любиш опинитися? У Selenium і Watin є рекордери, але Selenium є у браузері, а Wattin - у візуальній студії. + і -и обом цим.

Досі ми являємо собою чистий магазин Microsoft для надання рішень для підприємства та працювали з WatiN. Це може змінитися в майбутньому.

Як новітнє джерело:

Microsoft надрукувала в MSDN Magazine 12/2010 BDD-праймер із поєднанням SpecFlow з WatiN (крутий BDD-Behavior Driven Development). Її автор Брендон Сатром (msft Developer Evangelist) також опублікував у грудні 2010 року відео-веб-трансляцію з деталізацією 1: 1 своїх вищезазначених висновків.

Існує Whitepaper від 04/2011 по підтримці ATDD / BDD з SpecLog, SpecFlow і Team Foundation Server (Acceptance Test Driven Development / Behavior Driven Development) від Christian Хассе , чия команда побудована SpecFlow.

Я використовую Watin, але не використовував селен. Я можу сказати, що я швидко встав і біг на Ватін, і у мене було мало проблем. Я не можу придумати нічого, чого хотів би зробити, що не міг з цим зрозуміти. HTH

Я зазвичай використовую Selenium, головним чином тому, що мені подобається плагін Selenium IDE для FireFox для запису початкових точок моїх тестів.

Я рекомендую WebAii, оскільки саме в цьому я мав успіх, і при його використанні моїх захоплень було небагато. Я ніколи не пробував Selenium і не пам’ятаю, як багато використовував WaTiN, принаймні, не до того, щоб міг змусити його успішно працювати. Я не знаю жодної основи, яка витончено розглядає діалоги Windows, хоча WebAii має інтерфейс для реалізації ваших власних обробників діалогів.

Я розглядав можливість використання обох. Я використовував диктофон для Selenium, щоб створити кілька тестів у FF. Я спробував зробити те ж саме у Ватіні і виявив, що Watin Recorder (2.0.9.1228) абсолютно непридатний для наших сайтів . Здавалося, що сайт робить його в IE6 - робить наш сайт ефективно непридатним для запису. Ми не підтримуємо IE6. Я не зміг знайти жодного способу змінити браузер, який він використовує. Я знайшов там лише один Ватін-рекордер. Якщо є декілька або один, який постійно оновлюється, будь ласка, прокоментуйте.

IDE Selenium Recorder для Firefox простий у використанні та перевіряє порти на C #. Це не чудово в цьому. Я не зміг змусити перенести тестові набори до роботи, незважаючи на те, що читав допис у блозі чи два, який мав обхідні проблеми. Таким чином, є трохи маніпулювання згенерованим кодом. І все-таки він працює на 90%, і це краще, ніж альтернатива.

Що стосується моїх грошей / часу, селен перевершує простоту створення нових тестів . IE не має жодної хорошої панелі інструментів для розробників, яка знаходиться десь так добре, як Firebug , тому я починаю свою розробку в Firefox для початку, тому наявність хорошого робочого рекордера в Firefox - це величезний бонус.

Мій висновок тут був дуже схожий на цитату демократії Черчілля: Селен - це найгірша форма автоматизованого тестування на інтерфейс користувача. За винятком усіх інших.

Загрожуючи спуститися на дотичну, я рекомендую Ax / WatiN. Ax дозволяє тести писати в Excel «Тестувальниками», які не знають основної мови тесту. Потрібен "Технік", щоб записати відповідні дії (IE. Сьогодні мені довелося зробити трохи складний пошук таблиці та перехресне посилання), але колись написані дії можуть бути використані у тестах нетехнічними тестерами.

Я також чув, що проект урядового шлюзу уряду Великобританії (який, на мою думку, має автоматичні тести 6K + тести), нещодавно переніс усі свої тести з Ax / Winrunner в Ax / Watin протягом тижня !! І багато тестів досить складні - я знаю, як працював над ним кілька років тому ...

Я зараз дивлюся на Selenium, як потенційний клієнт використовує його. Але я пропоную поглянути на Сокиру як на шар, що знаходиться над інструментом «робочий кінь».

Якщо вам доведеться отримати доступ до iframes, модальних діалогів та міждоменних iframe WatiN - це шлях. Selenium не міг обробляти iframe, він викидав винятки командного часу. WatiN, ви можете зробити багато іншого, особливо якщо веб-сайт використовує специфічні для IE речі, такі як ShowModalDialog тощо. WatiN обробляє їх усі дуже добре. Я навіть міг зробити міждоменний iframe доступ.

Вам доведеться робити і те, і якщо вам потрібно зробити IE і FF тестування, але вони будуть працювати так добре для тестування презентації. Вони не можуть визначити, якщо один елемент трохи відключений, просто що елементи є. Я не знаю нічого, що може замінити людське око для тестування інтерфейсу користувача / презентації, хоча ви можете зробити кілька речей, щоб допомогти йому (робити скріншоти сторінок на кожному кроці, щоб користувачі могли їх переглянути).