xDrivenDevelopment
V4 Выполняет не все тесты, если установлен фиксированный порядок тестов
Коллеги, не знаю с чем связано, уже устал искать.
Есть версия раннера 4 и есть задача прогнать тесты в заданном порядке. Есть командная строка для ЗагрузчикФайла и тесты туда передаются через массив строк:
"C:\Program Files (x86)\1cv8\8.3.4.408\bin\1cv8.exe" ENTERPRISE /F"c:\Users\aovsyankin\Desktop\testxUnit\v8r_TempDB" /RunModeManagedApplication /Out"c:\Users\aovsyankin\Desktop\testxUnit\log.txt" /WA+ /DisableStartupMessages /DisableStartupDialogs /Execute"c:\Users\aovsyankin\Documents\GITs\xUnitFor1C\xddTestRunner.epf" /AllowExecuteScheduledJobs -Off /C"xddRun ЗагрузчикФайла c:\Users\aovsyankin\Documents\GITs\ntvr\tests\Тест1.epf
c:\Users\aovsyankin\Documents\GITs\ntvr\tests\Тест2.epf
c:\Users\aovsyankin\Documents\GITs\ntvr\tests\Тест3.epf
c:\Users\aovsyankin\Documents\GITs\ntvr\tests\Тест4.epf
c:\Users\aovsyankin\Documents\GITs\ntvr\tests\Тест5.epf
c:\Users\aovsyankin\Documents\GITs\ntvr\tests\ТестД6.epf
c:\Users\aovsyankin\Documents\GITs\ntvr\tests\Тест7.epf
c:\Users\aovsyankin\Documents\GITs\ntvr\tests\Тесты8.epf
c:\Users\aovsyankin\Documents\GITs\ntvr\tests\Тест9.epf;xddShutdown;xddReport ГенераторОтчетаJUnitXML c:\Users\aovsyankin\Desktop\testxUnit\logtest.xml"
Есть код загрузчика ЗагрузчикФайла:
Так вот, если выделенный комментарий раскомментировать, то прогоняет только первые три теста из списка. Если закоментировать - то прогоняет все 9, но в рандомном порядке.
Догадываюсь, что может быть завязано на конкретику тестов, но убейте не понимаю как. @artbear и @wizi4d могут догадаться, что тесты интимные, и приложить к задаче я их не могу, но я могу передать частным порядком.
@EvilBeaver
- Тесты в обработках как добавляются? через
ПолучитьСписокТестовилиЗаполнитьНаборТестов? - в коде самих тестов есть использование
НачатьГруппу?
Пробовал убирать тесты - двоичный поиск для поиска "плохого" теста ? Честно говоря, для меня сюрприз, что у нас по умолчанию может быть настроен рандомный порядок выполнения тестов :) Подождем @wizi4d
там нет "плохого", т.к. желаемый порядок был получен "рандомным" прохождением, а потом его потребовалось воспроизвести. Но повторить запуск с фиксированным порядком не получается.
Все понятно, это не баг, это фича! Все объясняет следующий код:
Если Не КонтейнерДереваТестов.СлучайныйПорядокВыполнения И ДочернийРезультатТестирования.Состояние <> Объект.СостоянияТестов.Пройден Тогда
Прервать;
КонецЕсли;
Если тесты выполняются в строгом порядке, то не имеет смысла продолжать шаги, если один из шагов упал.
Артур, а что тебя удивило в дефолтном поведении? Вроде так и планировали, что по умолчанию случайный порядок.
Артур, а что тебя удивило в дефолтном поведении? Вроде так и планировали, что по умолчанию случайный порядок.
Я почему-то считал, что у нас запуск в случайном порядке опционален. Лады, по этому поводу понятно.
Но как помочь @EvilBeaver с его задачей прогнать тесты в заданном порядке, причем это разные тестовые наборы/файлы ?
Я, конечно, давно уже размышляю о возможности строить связанные сценарии с помощью разных тестовых наборов/файлов, но пока никакое решение не принял.
Андрей, а напиши в личку (Hangouts нам с Женей), что за проблему вы встретили на тестов ntv...? У вас точно тесты не связаны, например, через общие изменяемые данные?
Эм, я думал, что уже все объяснил :smile: Дело в том, что у @EvilBeaver падает третий тест, что приводит к остановке выполнения в контейнере со строгим порядком.
Ах да, ты говоришь с учетом поведения с помощью указанной строки кода. А я говорю про поведение в ветке reborn, в которой этой строки на самом деле нет :)
Может быть, нам всем подумать над фичей сценарного выполнения тестов из разных наборов? и тогда @EvilBeaver не нужно будет фреймворк менять, что не гуд.
Тебя куда-то не туда занесло имхо. Насколько я понял, @EvilBeaver решает разовую локальную задачу. И это НЕ надо добавлять во фреймворк.
@wizi4d это плохая фича, ибо если есть неявная зависимость между тестами, которую надо устранить, то это вообще нельзя сделать на 4-й версии. Да, там посередине падучий тест, но у меня хрень с транзакциями где-то позже, я с падучим тестом позже разберусь. Как мне это сделать?
Ну т.е. за строчку кода спасибо, но вот такой кейс - прогона N тестов в заданном порядке и полностью - это вообще не поддерживается. Имхо, поведение при котором падение одного теста останавливает весь контейнер - неправильное.
Я специально, до в4, реализовывал возможность использования двойного поведения - тот порядок загрузки, что и у разработчика тестов, и случайный порядок тестов.
ИМХО Оба варианта использования бывают полезны, что и показывает текущая проблема.
@wizi4d @EvilBeaver давайте придем к какому-то решению!
Давайте рассмотрим поведение режима со строгим порядком. Он предназначен для случаев, когда есть некий порядок шагов, который нельзя нарушать. Назовем это СЦЕНАРИЙ. Теперь предположим сценарий состоит из 5 шагов. Если по какой-то причине 3-ий шаг выполнить нельзя, зачем выполнять 4 и 5? Сценарий уже нарушен. С этой точки зрения поведение верное. Вменяемого случая, когда нужно продолжать сценарий, я придумать не могу.
Теперь вернемся к конкретному случаю. По сути строгий порядок используется несколько необычным способом, для поиска бага (неявная зависимость). Варианты решения без порчи обозначеного выше проведения:
- Убрать из сценария подающий шаг (раз его падение считается не важным)
- Если шаг все же нужный с точки зрения влияния на другие шаги, то можно убрать из шага утверждения и он перестанет быть падающим и сценарий сможет быть продолжен
Изменение поведения у строгого порядка выполнения считаю костылем.
Артур, твой коммент не понял совсем.
15:51, Пн, 08.02.2016, Artur Ayukhanov [email protected]:
Я специально, до в4, реализовывал возможность использования двойного поведения - тот порядок загрузки, что и у разработчика тестов, и случайный порядок тестов.
ИМХО Оба варианта использования бывают полезны, что и показывает текущая проблема.
@wizi4d https://github.com/wizi4d @EvilBeaver https://github.com/EvilBeaver давайте придем к какому-то решению!
— Reply to this email directly or view it on GitHub https://github.com/xDrivenDevelopment/xUnitFor1C/issues/598#issuecomment-181354221 .
Фиксированный порядок это не всегда сценарий. Я как разработчик у которого готов набор тестов на нереализованный функционал хочу, чтобы отчет о падениях был в одном порядке на каждом запуске набора тестов. Сценария у меня реально нету, список ошибок мне нужен весь. Например я знаю, что первый тест у меня еще падает, но второй и третий должны уже проходить. С четвертого по двадцатый - снова падать.
8 февраля 2016 г., 23:32 пользователь Evgeniy Pavlyuk < [email protected]> написал:
Давайте рассмотрим поведение режима со строгим порядком. Он предназначен для случаев, когда есть некий порядок шагов, который нельзя нарушать. Назовем это СЦЕНАРИЙ. Теперь предположим сценарий состоит из 5 шагов. Если по какой-то причине 3-ий шаг выполнить нельзя, зачем выполнять 4 и 5? Сценарий уже нарушен. С этой точки зрения поведение верное. Вменяемого случая, когда нужно продолжать сценарий, я придумать не могу.
Теперь вернемся к конкретному случаю. По сути строгий порядок используется несколько необычным способом, для поиска бага (неявная зависимость). Варианты решения без порчи обозначеного выше проведения:
- Убрать из сценария подающий шаг (раз его падение стается не важным)
- Если шаг все же нужный с точки зрения влияния на другие шаги, то можно убрать из шага утверждения и он перестанет быть падающим и сценарий сможет быть продолжен
Измение поведения у строгого порядка выполнения считаю костылем.
Артур, твой коммент не понял совсем.
15:51, Пн, 08.02.2016, Artur Ayukhanov [email protected]:
Я специально, до в4, реализовывал возможность использования двойного поведения - тот порядок загрузки, что и у разработчика тестов, и случайный порядок тестов.
ИМХО Оба варианта использования бывают полезны, что и показывает текущая проблема.
@wizi4d https://github.com/wizi4d @EvilBeaver https://github.com/EvilBeaver давайте придем к какому-то решению!
— Reply to this email directly or view it on GitHub < https://github.com/xDrivenDevelopment/xUnitFor1C/issues/598#issuecomment-181354221>
.
— Reply to this email directly or view it on GitHub https://github.com/xDrivenDevelopment/xUnitFor1C/issues/598#issuecomment-181520945 .
Фиксированный порядок это не всегда сценарий. Я как разработчик у которого готов набор тестов на нереализованный функционал хочу, чтобы отчет о падениях был в одном порядке на каждом запуске набора тестов.
Ага, я также люблю фиксированный порядок при выдаче результатов тестирования.
Причем тут выдача результатов тестирования? Это совсем иная задача и решается другими способами. В UI раннера, кстати, это решено.
@Ndochp вопрос как раз не в гипотетических примерах использования, а в реальных. Фиксированный порядок = зависимость = сценарий.
Итого - как поддержать сценарий "повторяемости", когда вдруг встала неявная зависимость и нужно просто воспроизвести то же состояние прогона тестов?
Повторюсь:
- Убрать из сценария подающий шаг (раз его падение считается не важным)
- Если шаг все же нужный с точки зрения влияния на другие шаги, то можно убрать из шага утверждения и он перестанет быть падающим и сценарий сможет быть продолжен
эм. на мой взгляд, вот тут есть некоторое недопонимание.
Давайте рассмотрим поведение режима со строгим порядком. Он предназначен для случаев, когда есть некий порядок шагов, который нельзя нарушать. Назовем это СЦЕНАРИЙ. Теперь предположим сценарий состоит из 5 шагов. Если по какой-то причине 3-ий шаг выполнить нельзя, зачем выполнять 4 и 5? Сценарий уже нарушен.
Режим строгого порядка нужен для того, чтобы тесты выполнялись в строгом порядке. Все остальное - это уже накрутки и придумки.
Лучше я увижу 50 упавших тестов из 200, увидев, что первым упал 73й, а последним 122й, чем вообще пропущу целый кусок тестирования. Каким образом будут собираться и обрабатываться данные - это уже другой вопрос - я, например, вообще просто люблю читать билд-логи, а каждый раз разглядывать билдлог с новым порядком тяжело.
Вот такое имхо со стороны.
Режим строгого порядка нужен для того, чтобы тесты выполнялись в строгом порядке. Все остальное - это уже накрутки и придумки.
Не согласен с этим утверждением. Шаги выполняются в строгом порядке чтобы что? Они наверное зависимы?
Каким образом будут собираться и обрабатываться данные - это уже другой вопрос - я, например, вообще просто люблю читать билд-логи, а каждый раз разглядывать билдлог с новым порядком тяжело.
Этот аргумент верный и сводится к другой задаче. Нужно чтобы дерево с результатом тестирования при случайном выполнении соответствовало переданному дереву тестов.
Шаги выполняются в строгом порядке чтобы что? Они наверное зависимы?
не обязательно. но уж если они зависимы, то гарантировать, что от билда к билду не возникнет артефактных падений тестов.
Нужно чтобы дерево с результатом тестирования при случайном выполнении соответствовало переданному дереву тестов.
какое дерево, если я делаю Сообщить() или Лог.Информация() в односкрипте? или каждый тест запускается в новом шелле с перехватом вывода в родительском запускаторе? (я вообще не копался в раннере, может чего не понимаю)
Подытожу: у нас есть ДВЕ проблемы: 1 отображение результатов тестирования в порядке, заданном деревом тестов
дерево с результатом тестирования при случайном выполнении соответствовало переданному дереву тестов.
2 Разобраться с выполнением шагов в строгом порядке и сценарным/зависимым выполнением тесто
1 отображение результатов тестирования в порядке, заданном деревом тестов
дерево с результатом тестирования при случайном выполнении соответствовало переданному дереву тестов.
Создал #599 Давайте отображение результатов тестирования обсуждать там
Здесь будем разбираться именно с выполнением шагов в строгом порядке и сценарным/зависимым выполнением тестов
Шаги выполняются в строгом порядке чтобы что? Они наверное зависимы?
не обязательно. но уж если они зависимы, то гарантировать, что от билда к билду не возникнет артефактных падений тестов.
Интересная точка зрения. С одной стороны, с зависимостью тестов нужно бороться, а с другой, неожиданные падения при случайном прогоне тестов лечатся совсем не легко :( и я понимаю желание избавиться от подобных артефактных падений тестов.
Я руководствуюсь следующей методологией:
- Тесты должны быть изолированными друг от друга. Завет дядьки Кента Бека. Это обеспечивает случайный порядок выполнения.
- Исключение возможно только при работе с тестами как со сценариями со строгим порядком выполнения. Веяние бдд.
Внимание вопросы: Зачем менять эту методологию? Что в ней не так?
18:12, Вт, 09.02.2016, Artur Ayukhanov [email protected]:
1 отображение результатов тестирования в порядке, заданном деревом тестов
дерево с результатом тестирования при случайном выполнении соответствовало переданному дереву тестов.
Создал #599 https://github.com/xDrivenDevelopment/xUnitFor1C/issues/599 Давайте отображение результатов тестирования обсуждать там
Здесь будем разбираться именно с выполнением шагов в строгом порядке и сценарным/зависимым выполнением тестов
— Reply to this email directly or view it on GitHub https://github.com/xDrivenDevelopment/xUnitFor1C/issues/598#issuecomment-181909213 .
@wizi4d Женя, и я разрабатываю по этим же принципам :)
Но еще мне хочется понять желания пользователей и предложить им вменяемый вариант решения их проблемы :)
- Тесты должны быть изолированными друг от друга. Завет дядьки Кента Бека. Это обеспечивает случайный порядок выполнения.
На самом деле случайный порядок это один из элементов выполнения требования изолированности. Не менее важно использовать режим транзакций :)
Дяденьки, извините, что я тут со своими глупостями лезу... Не знаю, чем закончится обсуждение, но меня волнует вопрос: у меня тест к примеру создания счета-фактуры рассчитывает на то, что тест проведения накладной выполнился успешно, и никаких проверок на наличие/проведенность уже не делается. Просьба просто иметь это в виду, если будет принято решение продолжать выполнение тетов при поломке для строгого порядка.
@rsyuzyov У тебя как раз проблема сильной зависимости тестов друг от друга.
Тебе рекомендуем юзать сценарный тест. Почитай, как разрабатывать сценарные тесты для версии 4 Почитай, как разрабатывать сценарные тесты для версии 3
@wizi4d В методологии все хорошо.
Но (Артур, прости, что опять перекликаюсь с задачей вывода). Банальная ситуация - travis_ci/gilab_ci. логи в реальном времени, красота. Если обеспечивать вывод постоянных в своем порядке логов в консоль только после полной обработки (#599 же об этом, да?) , то... мы будем 10 минут смотреть в пустой черный экран, а потом получим несколько сотен/тысяч строк текста.
Жень, я не говорю, что случайный порядок тестов - это плохо и не правильно. изолированность, атомарность - это все хорошо и нужно. Я просто прошу учесть, что неслучайный порядок - это не всегда сценарий/связанность данных/группа тестов. И если есть такая потребность (не важно, чем она вызвана, ошибками в применении методологии или какими-то техническими/эстетическими/whatever заморочками автора тестов) и в целом-то функционал для обеспечения этой потребности тоже уже есть, то зачем его зарезать?