Заказ на тестирование носа Джанго

Я использую нос с django-nose для своих тестов

Но у меня проблемы с разумным заказом тестов.

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

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

Что мне не хватает? Кто-нибудь сталкивался с такой же проблемой?

Побочная информация: я тестирую серию из ~ 10 действий, поэтому я бы возражал, особенно в моем случае, против «изоляции теста»; необходимость переписывать прошлые действия для каждого теста, на мой взгляд, просто не самая умная и неэффективная по времени ... и именно здесь должен вступить в действие порядок выполнения.

Я знаю, что этот плагин Nose для указания порядок выполнения модульного теста , но я не могу правильно «настроить» плагин для носа, а ответ на имя функции не работает

Спасибо большое


python django unit-testing nose django-nose
person Ramez Ashraf    schedule 28.04.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

После почти двух дней непрерывных исследований я решил, что это не тот путь, и в основном я отказался от тестирования этой функции в качестве «модульного теста».

Знаете ли вы, что setUp и Tear Down выполняются для «каждой функции» в вашем тестовом примере?!! Я не знал!!! :)

я пришел к выводу/пониманию, что модульный тест предназначен для тестирования модуля (DAH!), что означает тестирование функции a, а не нескольких взаимосвязанных или «сложных» классов, которые вычисляют и обновляют базу данных...

Такие вещи и то, что я хочу протестировать, относятся к другой категории, «поведенческому» тестированию. Я видел очень полезное видео рассказ Малкома о тестировании и поведенческом тестировании и демонстрацию этого пакета Поведение

Напишу как все было на самом деле, всем удачи

person Ramez Ashraf    schedule 30.04.2014
comment
Обратите внимание, что хотя модульное тестирование как методология предназначено для изолированного тестирования, большинство инструментов модульного тестирования на самом деле не мешают вам выполнять функциональное, поведенческое или интеграционное тестирование. Если вы хотите поделиться тестовой фикстурой, вы можете использовать setUpModule()/tearDownModule(). Сказав это, даже при более высоком уровне тестирования вы все равно должны стремиться избежать зависимости от порядка. Если ваши тесты зависят друг от друга, возможно, вместо этого они должны быть одним большим тестом. - person Lie Ryan; 30.04.2014
comment
Спасибо, Райан. Да, модуль на самом деле не мешает, но делает это ОЧЕНЬ ТЯЖЕЛЫМ. На самом деле я сделал это в одном большом огромном блоке, но тогда, если одно утверждение терпит неудачу, я не вижу, были ли другие тесты успешными или нет. Я также пробовал SetUpClass, но у меня было много проблем с передачей связанной переменной. Светильники были ... эх ... слишком хлопотными, поскольку я только начинаю проект, поэтому схема часто подвергается серьезным изменениям. :) - person Ramez Ashraf; 30.04.2014
comment
Обратите внимание, что я не имел в виду приспособление django; тестовое приспособление — это в основном состояние, которое вы получаете после вызова команд setUp*. Фреймворки модульных тестов не усложняют интеграционное тестирование, интеграционное тестирование сложно по своей сути. Проблема в том, что вам нужно балансировать между медленной, но тщательной очисткой и быстрой, но оставляющей следы, которые потенциально могут повлиять на воспроизводимость теста. Если вы откажетесь от изоляции, как среда тестирования сможет узнать, какие тесты могут продолжаться, если текущий не пройден? - person Lie Ryan; 30.04.2014