Сообщений в теме: 9

[mosketrem]

Был на конференции SeleniumCamp. На своем докладе А.Баранцев рассказывал о способах оптимизации тестов. Один такой способ: запускать браузер наименьшее количество раз, т.е. один раз запустили и проганяете максимальное количество тестов в нем. Но так как я зашел в зал как раз, когда он заканчивал об этом рассказывать, а также потому, что я пишу на питоне, а не на java, я не понял как мне организовать такое поведение в моих тестах.
Может предложите конкретное решение для Selenium RC + python ? Я почему-то не могу сообразить. Разве что использовать следующую структуру:

from selenium import selenium
import unittest, time, re

class Untitled(unittest.TestCase):
    def setUp(self):
        self.verificationErrors = []
        self.selenium = selenium("localhost", 4444, "*chrome", "http://change-this-to-the-site-you-are-testing/")
        self.selenium.start()
    
    def test_untitled1(self):
        sel = self.selenium
    
    def test_untitled2(self):
        sel = self.selenium

    def test_untitled3(self):
        sel = self.selenium

    def tearDown(self):
        self.selenium.stop()
        self.assertEqual([], self.verificationErrors)

if __name__ == "__main__":
    unittest.main()

[SMakc]

Не знаю чем руководствовался Баранцев, но мы для атомарности для каждого нового теста запускаем новую сессию, что конечно сказывается на производительности, но позволяет избежать ошибок тестов из за "грязной" сессии.

[OVA]

Ну это зависит. Убивать сессию/чистить кеш/блаблабла по пять раз для проверки пары чекбоксов совсем не эффективно по времени.

[bobax]

мы сами пришли к этому, о чем говорил Баранцев. т.к. наша среда ИЕ8, то куки-кеш-сессии убиваются нагорячую через микрософт девелопер тул встроенный

[mosketrem]

Не знаю чем руководствовался Баранцев, но мы для атомарности для каждого нового теста запускаем новую сессию, что конечно сказывается на производительности, но позволяет избежать ошибок тестов из за "грязной" сессии.

Вы совершенно правы на счет ошибок из-за "грязной" сессии. Но Баранцев объяснил свое предложение соответствием поведения тестов работе обычных пользователей. Ведь обычный пользователь не закрывает браузер после каждого простого действия. А если из-за таких сессий валятся тесты, значит мы нашли баг и его нужно репортить и исправлять. Я думаю, что в этом есть смысл.

Как бы то ни было, думаю не стоит превращать тему в спор на счет полезности такого поведения. Мне бы хотелось просто узнать как это правильно сделать.

[bobax]

судя по рассуждениям и так и так правильно) на усмотрение тест менеджера)

[barancev]

http://docs.python.o...module-fixtures

[barancev]

Либо можно использовать не стандартный фреймворк unittest, а более навороченный py.test, вот соответствующий фрагмент его документации: http://pytest.org/xunit_setup.html

[polus]

http://docs.python.o...module-fixtures

Единственное замечание, чтобы использовать setUpClass и tearDownClass, необходимо использовать питон версии версии 3 или уже ставить его руками для версии не ниже 2.7

[barancev]

http://docs.python.o...module-fixtures

Единственное замечание, чтобы использовать setUpClass и tearDownClass, необходимо использовать питон версии версии 3 или уже ставить его руками для версии не ниже 2.7

Даже не версии 3, а версии 3.2 (там в документации по ссылке про это написано).
Так что я бы всё таки рекомендовал использовать py.test, если версия ниже 3.2, ставить новые модули на старый дистрибутив рискованно.