Найти - Пользователи
Полная версия: Юниттесты
Начало » Флейм » Юниттесты
1 2 3
Kogrom
Андрей Светлов
Предложите, как лучше написать - пока не представляю, как выразить эту мысль в коротком абзаце.
Когда писал статью - пытался вставить упоминания о “разноцветных ящиках”, - но это только запутывало изложение.
Может, в начале или (что лучше) в конце добавить параграф с четкими определениями? Опять же, на сегодня я не готов этот текст составить.
Всё написано хорошо. Некоторое непонимание может вызвать это: “Постановка задачи: требуется регрессионный тест”. Тут можно понять, что юниттесты не являются регрессионными. Возможно, лучше было бы после упоминания ручного тестирования написать что-то типа: “к счастью, регрессионные тесты не ограничиваются только юнит-тестами. Есть ещё и регрессионные функциональные тесты, которые требуют больше ресурсов и времени, но зато более близки к ручному тестированию”. А дальше уже переходить к постановке задачи.

Упоминание “чёрных и белых” ящиков может привести к холивару. Шучу.
Андрей Светлов
Kogrom, я сделал как вы предложили.
Если хотите - заменю слово Kogrom на url, ведущий на вашу любимую страничку. Только скажите - на какую.
Очень ценю ваши конструктивные предложения.

И, так уж получилось, старожилов форума часто знаю по имени, а иногда и встречались лично.
Вы уж извините, что использую к вам обращение во втором лице и ссылаюсь просто на ваш ник.
helm2004
Андрей Светлов
Богдан, а можешь ли хотя бы коротко описать то средство, которым вы пользуетесь на работе? Мне весьма интересно.
И мне интересно.
Kogrom
Андрей Светлов
Если хотите - заменю слово Kogrom на url, ведущий на вашу любимую страничку. Только скажите - на какую.
Не надо. Любимой странички нет. И я больше известен по нику, чем по имени, так что мне приемлемо. Можно вообще убрать упоминание конкретного персонажа, а сослаться на обсуждения в форумах. Заодно и форум попиарим :)
Андрей Светлов
Хорошо
Ferroman
У нас всё настолько просто, насколько возможно. Даже и рассказывать особо нечего
Поскольку у нас всё больше джанга, то ничего стороннего не используем — встроенной в фреймоворк поддержки юнит-тестировнаия достаточно.
Основным отличием от прочитанного мной ранее о тестировании и от чужих тестов вообще есть максимальная атомарность отдельных тестов, а так же максимальная ясность в описании тестируемого поведения кода. Стараемся чётко определять какой слой тестируем — от этого зависит какие детали реализации могут быть известны тесту. (Грубо говоря, тесты у нас разделены на юнит-тесты (low-level), acceptance тесты (hight-level) и integration тесты (зависит от контекста))
Пример accepted теста:
class ProfileBeginDownloadTest(BaseViewTest):
def test_should_redirect_to_login_page_when_user_was_not_previously_logged_in(self):
response = self.client.get("/panel/profile/begindownload/poppy/ie/")
self.assertRedirect(response, "http://testserver/panel/login/?next=/panel/profile/begindownload/poppy/ie/")

def test_should_response_with_404_when_download_requested_for_non_supported_browser(self):
self._login()
response = self.client.get("/panel/profile/begindownload/Consumer Input/opera/")
self.assertEquals(404, response.status_code)

def test_should_response_with_ie_software_download_redirect_for_ie_browser(self):
self._login()
response = self.client.get("/panel/profile/begindownload/Consumer Input/ie/")
self.assertRedirect(response, ConsumerInputPanels.objects.getIESoftwarePath("poppy"))
Обычного юнит-теста
class AgeValidatorTest(TestCase):
def test_should_fail_when_non_numeric_value_passed(self):
self.failUnlessRaises(ValidationError, age_validator, "sixteen")

def test_should_fail_when_less_than_minimum_age_passed(self):
self.failUnlessRaises(ValidationError, age_validator, "17")

def test_should_fail_when_greater_than_maximum_age_passed(self):
self.failUnlessRaises(ValidationError, age_validator, "111")

def test_should_pass_when_minimum_age_passed(self):
age_validator("18")

def test_should_pass_when_greater_than_minimum_age_passed(self):
age_validator("50")

def test_should_pass_when_maximum_age_passed(self):
age_validator("110")
И integration тест
class ValidateApiUserAgentDataMapperTest(TestCase):
fixtures = ["test_panels.json"]

def setUp(self):
self.panel = ConsumerInputPanels.objects.get(id="poppy")
self.invalid_error_code = 1
self.mapper = ValidateApiUserAgentDataMapper(self.panel, self.invalid_error_code)

def test_should_pass_validation_when_user_valid_agent_parameter_passed(self):
self.mapper.collect_data({"user_agent": self.VALID_USER_AGENT})
self.mapper.validate()

def test_should_fail_validation_when_user_invalid_agent_parameter_passed(self):
self.mapper.collect_data({"user_agent": self.INVALID_USER_AGENT})
self.failUnlessRaises(DataMapperValidationError, self.mapper.validate)
Андрей Светлов
А как же быть с javascript? В модульных - фиг с ним. Но в acceptance стоило бы проверять.
И запускаете как? Врукопашную или какой Hudson прикрутили?
Ferroman
С javascript у нас беда совсем. Сейчас вот думаем как бы selenium прикрутить, даже вот на выходных на Selenium Camp ездил послушать что нас ждёт в этом направлении. Пока что QA руками ловят.
Hudson, конечно, но живём пока без автоматического деплоймента.
Андрей Светлов
Неделю назад случайно увидел https://github.com/idealistdev/alfajor/
Насколько понял, может использоваться и как надстройка над Selenium в unittest стиле - совсем как ваши acceptance.
Ferroman
Что-то я не проникся. В чём, собственно, profit? Вообще-то, тот же селениум IDE и так генерил практически готовые тесты в стиле стандартных питоновских.
Да и в планах снести всё acceptance на QA, а у себя делать только критичные, или по результатам найденых багов.
У разработчиков беда с javascript, в основном, из-за полного отсутствия юниттестов.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB