Python-сообщество

Новая статья на избитую тему
http://asvetlov.blogspot.com/2011/02/funny-unittests.html

Вторая часть марлезонского балета - регрессионные тесты
http://asvetlov.blogspot.com/2011/02/regression-tests.html

Андрей Светлов
Вторая часть марлезонского балета - регрессионные тесты
http://asvetlov.blogspot.com/2011/02/regression-tests.html

Вот это интересно. Пока не вникал в тонкости, но есть 2 вопроса:

1. Если вникать в терминологию, то юниттесты - это тоже регрессионные тесты. Поэтому разделение не совсем корректное. Хотя, могу заблуждаться.

2. Классы Executor и Q являются самодельными инструментами. Неужели для консоли нет готовых инструментов?

Спасибо за статью.

Пожалуйста.

Я привык называть регрессионными подмножество функциональных тестов. Может, моя терминология неверна.
Может, инструменты и есть. Я о них не знаю, а сделать “на коленке” получилось очень быстро. Как я писал, для Веба брал бы готовое решение.

То что ты описал, это скорее acceptence тесты.
У нас, кстати, на проектах организация тестов довольно сильно отличается, но только в части именно организации и составления тесткейсов и тестов.

можно называть их и QA - суть не меняется :)
Я видел довольно много способов “делать это” и почти каждый раз именовали чуть иначе.
Главное - чтобы механизм *был*.

Это доволно интересная тенденция (с именованиями), учитывая тот факт что разновидностей тестов очень немного и перепутать их сложно — слишком разные вещи тестируются.
Терминология важна — да ты и сам это знаешь. Хотя, конечно, понятно что хотел сказать.

Посмотрел, что говорит Википедия.
http://en.wikipedia.org/wiki/Category:Software_testing - видов тестирования бывает дофига.

Acceptance testing то же самое, что и Functional testing
http://en.wikipedia.org/wiki/Acceptance_testing: … It is also known as functional testing, black-box testing

Функциональные: http://en.wikipedia.org/wiki/Functional_testing
Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
Functional testing differs from system testing in that functional testing "verif a program by checking it against … design document(s) or specification(s)“, while system testing ”validate a program by checking it against the published user or system requirements"(Kaner, Falk, Nguyen 1999, p. 52).
Фраза про отличие функциональных от системных несколько расплывчата, ну да ладно.

Регрессионные: http://en.wikipedia.org/wiki/Regression_testing

Regression tests can be broadly categorized as functional tests or unit tests. В некоторых проектах (библиотеках, Питоне как таковом) регрессионные тесты сделаны как модульные.
В моем случае это - функциональные тесты.

Про юниттесты, надеюсь, ясно и без цитат.

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

Тема выглядит довольно запутанной, а классификация - не очень твердо устоявшейся. Тем не менее, кажется, она моим определениям не противоречит.

Андрей Светлов
Regression tests can be broadly categorized as functional tests or unit tests. В некоторых проектах (библиотеках, Питоне как таковом) регрессионные тесты сделаны как модульные.
В моем случае это - функциональные тесты.

Вот к этому выводу и я пришёл. То есть противопоставляются функциональные тесты и юниттесты, а не регрессионные тесты и юниттесты.

На счёт инструментов “сделанных на коленке”: интересно почитать, как такое может реализовано, но когда собираешься использовать, то возникают некоторые сомнения, что будешь используешь велосипед. Поэтому я этот вопрос и задал - может кто-нибудь знает альтернативы.

С другой стороны, это решение компактное, поэтому может быть и лучше его использовать, чем дополнительные пакеты.

Вижу, термины “функциональных”, “регрессионных” или “acceptance” тестов вызывают разночтения. И неочевидно их противопоставление модульным тестам.
Я, возможно, немного позже попытаюсь добавить в статью разъяснения по используемой классификации.

Пожалуйста, помогите мне. Предложите, как лучше написать - пока не представляю, как выразить эту мысль в коротком абзаце.
Когда писал статью - пытался вставить упоминания о “разноцветных ящиках”, - но это только запутывало изложение.
Может, в начале или (что лучше) в конце добавить параграф с четкими определениями? Опять же, на сегодня я не готов этот текст составить.

Я, как говорил, альтернативы для консольных тестов мне неизвестны. Честно сказать, и для GUI мы делали нечто своё - уж слишком эти GUI библиотеки разные.
Слышал, есть средства, “кликающие по кнопкам” - но ни разу их не использовал.

Для консоли мой “порог вхождения” был один час с момента первой наивной реализации до последнего рабочего варианта. Не уверен, что на изучение стороннего инструмента я потратил бы меньше. Разве что если бы он сразу давал очень мощные возможности.

Ferroman
Богдан, а можешь ли хотя бы коротко описать то средство, которым вы пользуетесь на работе? Мне весьма интересно.