моки и стабы. моки - эмулируют ответы других компонентов на основании запросов, стабы - отдают заранее заготовленные ответы. странно, что ты прочитал про юнит-тесты и ни разу о них не слышал.

Как такое тестировать, держать вместе с тестами эталонные файлы?

Да.

вот есть некий функционал, который активно работает с гуем, читает, генерирует и/или заполняет его динамические части. Такое вообще тестируется?

Да. Я, правда, не пробовал: https://fedorahosted.org/dogtail/ http://pedromateo.github.io/openhmitester/

Создавать временные файлы силами тестов?

Да, это нормальный способ тестирования. Только репозиторий не засирай, создавай в /tmp где-нить.

Однако, часто тесты не получается написать потому что код говно. Крайне рекомендую почитать вот это: http://misko.hevery.com/2008/07/30/top-10-things-which-make-your-code-hard-to...

Либо, на русском, по-моему, те же яйца, но с примерами: https://habrahabr.ru/company/mailru/blog/267277/

И ещё момент. Ты хочешь именно unit-тесты или интеграционные тесты? Я всегда советую иметь хотя бы парочку простых «fullstack» тестов чтобы убедиться что продукт вообще работает. А то может быть так что unit-тесты оно проходит, но насамом деле ничего не работает.

то, что ты описываешь - эталонные файлы, тестирование UI (в большинстве своем, бывают и исключения) - это не юнит-тесты, а модульные или интеграционные, зависит как их писать. падаван, мне кажется, не совсем правильно выбирает уровень детализации для тестов, наговнякав все в одну функцию, которая делает от фс до условной базы. ясен хрен, юнит-тесты на неё очень больно натягивать

функция работает с файловой системой - парсит заданную директорию, ищет определенные медиа файлы, выполняет манипуляции над ними

Это неправильно.
Правильно вот так:

• Первая функция парсит дирректорию
  
• Вторая функция ищет в распарсеном
  
• Третья функция выполняет манипуляции
  

Вот это уже можно тестировать.
А у тебя получается спагетти, к которым юнит-тестирование неприменимо.

У тебя в любом случае с таким подходом получится функциональное тестирование.

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

Тоже неправильно.
Надо разбить спагетти на независимые функции и в нужном месте собирать из них бусы.
Это и тестопригодно и код получается гораздо более читаемым.

«Пример у меня в профиле», хотел написать я, но заметил как одному неадекватному вахтёру прорвало анус от моего профиля.
Так что нигде, ЛОР это давно уже не технический форум.

то, что ты описываешь - эталонные файлы, тестирование UI (в большинстве своем, бывают и исключения) - это не юнит-тесты

Я и не говорил, что юнит. В хедпосте задано сразу много вопросов, я ответил на два, не подразумевая связи между ними.

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

У меня не создалось такого впечатления. Но, естественно, вкрячивать всё в одну функцию - плохо, при написании тестов тоже следует соблюдать модульность.

Да, это нормальный способ тестирования. Только репозиторий не засирай, создавай в /tmp где-нить.

вообще-то нет. файлы тянут за собой время на их создание, лишние зависимости в тестах, возможные баги с ФС, etc. поэтому в юнит-тестах они, как и работа с БД, эмулируются, а тестируются в интеграционных тестах.

Я всегда советую иметь хотя бы парочку простых «fullstack» тестов чтобы убедиться что продукт вообще работает. А то может быть так что unit-тесты оно проходит, но насамом деле ничего не работает.

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

лишние зависимости в тестах, возможные баги с ФС,

WAT? Наоборот, мы в тесты включаем ФС. Настоящую, реальную, ту что будет крутится на продакшене (в идеале, я держу dev максимально похожим на продакшн). Используя моккинг мы эту часть исключаем. Задумайся над этим. Ну и таки реальные проекты тестируются на тестовых наборах данных которые лежат в виде файлов/бд/etc.

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

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

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

Ты хочешь именно unit-тесты или интеграционные тесты?

Данный конкретный топик скорее именно про юнит тесты.

наговнякав все в одну функцию, которая делает от фс до условной базы. ясен хрен, юнит-тесты на неё очень больно натягивать

Ну что за лор, чуть что сразу «наговнякав».

Вообще «все в одну функцию» это насчет тестов или насчет самого кода? Первого пока вообще нет, второе довольно дискретно, кроме гуи части.

Это неправильно.
Правильно вот так:

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

Наоборот, мы в тесты включаем ФС. Настоящую, реальную, ту что будет крутится на продакшене (в идеале, я держу dev максимально похожим на продакшн).

в интеграционные? в юнит? во все подряд как получится? задумайся над этим.

Ты сейчас написал что интеграционные тесты не нужны что-ли?

вот туда же, читать не умеют, а лезут.

Я не говорил что одно другое заменяет.

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

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

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

Покрытие же всех возможных путей выполнения... Ты пошутил?

обычно кавередж у нас на проектах пляшет в районе 80% по строкам и 60% по условиям в модульных/интеграционных тестах примерно 80/20. учитывая обработчики ошибок, которые автотестами ловить больно - ну не все, но 90-95% путей выполнения у нас покрыты, в основном модульными тестами, которые, о чем я изначально и писал, позволяют не плодить интеграционные тесты в безумных количествах.

давай не будем превращать дискуссию в задротство «кто больше умных книжек по тестированию прочитал и знаем много умных терминов»

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

тебе это нужно для проверки работы *одного* модуля, а ты написал как будто это нужно для проверки *трех* модулей, что очевидная ересь. вот этот один, который общается с ФС - можешь замокать, конечно, можешь оставить на интеграционные тесты. труадмина не слушай, он, похоже, никогда не разбирал авгиевы конюшни, которые кто-то до него называл тестами - либо интеграционные тесты и реальные ФС и база, либо юнит-тесты и заглушки вместо них.

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

Можно детальную процедуру вычисления «кол-ва» интеграционных тестов исходя из покрытия юнит-тестами? Особенно, например, в ситуации когда есть большой legacy-проект не покрытый тестами вообще никак. И код нетестируемый. Ой, да, я знаю ответ — надо всё переписать :).

Опять-таки, ты понимаешь зачем нужны fullstack тесты? Чтобы знать что ничего не отвалилось, даже если по-отдельности работает хорошо. Без них — никуда, даже если там код на 100% покрыт юнит-тестами.

либо интеграционные тесты и реальные ФС и база, либо юнит-тесты и заглушки вместо них.

Я никогда не говорил обратного. Я просто сразу понял что ТС путается в терминологии и делает тесты которые охватывают несколько сущностей.

Выкини на помойку ушибленный жабкой unittest и возьми py.test. В доках к нему есть ответы на все твои вопросы.

Кусок фс нужен для функционального тестирования.
Для юнитов это явный перебор.

Можно детальную процедуру вычисления «кол-ва» интеграционных тестов исходя из покрытия юнит-тестами? Особенно, например, в ситуации когда есть большой legacy-проект не покрытый тестами вообще никак. И код нетестируемый. Ой, да, я знаю ответ — надо всё переписать :).

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

Опять-таки, ты понимаешь зачем нужны fullstack тесты? Чтобы знать что ничего не отвалилось, даже если по-отдельности работает хорошо. Без них — никуда, даже если там код на 100% покрыт юнит-тестами.

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

либо интеграционные тесты и реальные ФС и база, либо юнит-тесты и заглушки вместо них

Ок, vostrik, true_admin, эту идею я понял, буду еще заполнять пробелы в понимании структуры тестов.

Вопрос забегая вперед, если будет нужно кусок ФС для интеграционных тестов, его лучше просто держать в готовом виде вместе с тестами, или генерировать на лету (в моем случае возмоно) и подтирать временные файлы после завершения тестов?

файлы тянут за собой время на их создание, лишние зависимости в тестах, возможные баги с ФС, etc. поэтому в юнит-тестах они, как и работа с БД, эмулируются, а тестируются в интеграционных тестах.

WAT? Наоборот, мы в тесты включаем ФС. Настоящую, реальную, ту что будет крутится на продакшене (в идеале, я держу dev максимально похожим на продакшн). Используя моккинг мы эту часть исключаем. Задумайся над этим. Ну и таки реальные проекты тестируются на тестовых наборах данных которые лежат в виде файлов/бд/etc.

Я никогда не говорил обратного

лан

Я просто сразу понял что ТС путается в терминологии и делает тесты которые охватывают несколько сущностей.

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

Выкини на помойку ушибленный жабкой unittest и возьми py.test

Вот это серьезно? Вроде unittest в комплекте с самим питоном, значит православен и одобрен, не?

Кроме вот этого:

Или вот есть некий функционал, который активно работает с гуем, читает, генерирует и/или заполняет его динамические части. Такое вообще тестируется?

Выносишь максимум логики подальше от гуя и спокойно тестируешь.

если будет нужно кусок ФС для интеграционных тестов, его лучше просто держать в готовом виде вместе с тестами

для интеграционных тестов полезно иметь тестовую виртуалку (ну или докер и прочее хипстерское барахло), полностью повторяющее продакшн, и разворачивать её перед прогоном интеграционных тестов.

или генерировать на лету (в моем случае возмоно)

NO

подтирать временные файлы после завершения тестов?

это не только к файлам относится.

число интеграционных тестов нужно к минимуму

Что ты вкладываешь в «к минимуму»? Вот давай на конкретном примере разберём, мой случай. Есть сайт с пользователями. И у меня есть тесты которые 1) создают новый аккаунт 2) заходят на сайт с этими креденшилами 3) делают типовые задачи (в первую очередь те, за которые деньги платят). Тут не идёт речи о покрытии всех возможных путей исполнения. Я делаю всё неправильно? Уточню, на всякий случай, что сайт состоит из нескольких блоков: фронтенд, бэкенд, сервер уведомлений, сторадж на амазоне и ещё несколько сторонних «облачных» сервисов. Тесты (хоть какие-то) есть только на тот код что писал я :).

Давай в расчёт примем то что очень много js-кода используется в виде библиотек, многие не содержат тестов. Даже те что тестируются иногда ломают обратную совместимость без внятных записей в чейнжлоге. Т.е., даже если с нашей стороны всё протестировано (что, увы, неправда) всё равно есть куча стороннего кода которая при обновлении легко может обвалиться. И моё покрытие основного функционала тестами уже успешно выявило такие проблемы. А что бы мне дало покрытие юнит-тестами в этом случае? Ну, как бы всё по-отдельности работает.

Вроде unittest в комплекте с самим питоном, значит православен и одобрен, не?

В питонячьей stdlib полно сомнительных решений. unittest одно из них. urllib2 как еще один пример. logging тоже слизан с жабки, но он по крайней мере привычен после нее и особых плюшек питона к нему не прикрутить.

За одну возможность просто делать assert func() == value можно никогда не вспоминать про unittest

если будет нужно кусок ФС для интеграционных тестов, его лучше просто держать в готовом виде вместе с тестами, или генерировать на лету (в моем случае возмоно) и подтирать временные файлы после завершения тестов?

В общем случае пофиг, но есть много нюансов. Например, «повторяемость тестов» (чтобы твоему напарнику не пришлось клянчить твой набор тестовых данных когда у него всё работает, а у тебя падает, объём тестов, время генерации этих данных (тесты которые слишком долго выполняются — зло, но не всегда это можно избежать).

Иногда тестовые данные хранят отдельно, когда, скажем, набор данных актуален для нескольких модулей/программ итп.

В реальности встречаются оба подхода. Но я бы хранил рядом ради повторяемости.

Что касается мусора то чем меньше тем лучше (и не засирать папку с исходниками). Но, опять-таки, есть нюансы. Например, я рекомендую хранить хлам в /tmp, но только если нет риска, скажем, забить его целиком, /tmp обычно в памяти лежит. Ещё момент, сделай так чтобы не было race condition. Т.е. используй уникальные имена в /tmp. А то был случай когда один проект тестировался в несколько потоков и они писали в одно и тоже место.

py.test

Его нужно использовать хотя бы за assert introspection :)

Ещё момент, сделай так чтобы не было race condition. Т.е. используй уникальные имена в /tmp

py.test даже это берет на себя.

для интеграционных тестов полезно иметь тестовую виртуалку

Не, ну это как-то хардкорно, у меня там поделка на пару-тройку тысяч строк, просто на ее примере хочу попробовать сделать все «как надо».

Что ты вкладываешь в «к минимуму»?

покрытие взаимодействия между основными компонентами

Вот давай на конкретном примере разберём, мой случай. Есть сайт с пользователями. И у меня есть тесты которые 1) создают новый аккаунт 2) заходят на сайт с этими креденшилами 3) делают типовые задачи (в первую очередь те, за которые деньги платят). Тут не идёт речи о покрытии всех возможных путей исполнения.

1 и 2 дублируют друг друга, тк проверяют только взаимодействие фронтенда и бэкенда (ну, если там не какой-то экзотический механизм регистрации), единственное их объяснение - они взаимозависимы (что тоже плохо, где атомарность, а?). 3 - задачи, за которые платят деньги, должны быть покрыты полностью, как минимум все позитивные флоу. чем натяпляпать пару тестов - лучше вообще не тестировать, не будешь лишних иллюзий питать, мол у нас там тесты с пейджобжектами, у нас все хорошо. что должны проверить твои тесты - r/w взаимодействие фронтенда и бэкенда, взаимодействие бэкенда (а может и фронтенда) с 3rd party сервисами, попутно проверив работу с железом (строго говоря, если они выполнились - ну значит как минимум бэкенд не в воздухе летает, а как-то с железом взаимодействует)

Я делаю всё неправильно?

типикал кейс «тестирование исходя из здравого смысла», который ни на каплю не дает уверенности в том, что тестирование зачем-то нужно

Уточню, на всякий случай, что сайт состоит из нескольких блоков: фронтенд, бэкенд, сервер уведомлений, сторадж на амазоне и ещё несколько сторонних «облачных» сервисов. Тесты (хоть какие-то) есть только на тот код что писал я :).

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

Давай в расчёт примем то что очень много js-кода используется в виде библиотек, многие не содержат тестов. Даже те что тестируются иногда ломают обратную совместимость без внятных записей в чейнжлоге. Т.е., даже если с нашей стороны всё протестировано (что, увы, неправда) всё равно есть куча стороннего кода которая при обновлении легко может обвалиться.

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

И моё покрытие основного функционала тестами уже успешно выявило такие проблемы.

точно так же его бы выявило покрытие всего используемого кода тестами. но в первом случае ты что-то где-то отловил, потому что повезло, затратив кучу времени и ресурсов на написание end-to-end тестов там, где они не нужны. во втором случае ты бы хотя бы имел преставление о том, что у тебя оттестировано, в отличие от первого.

А что бы мне дало покрытие юнит-тестами в этом случае? Ну, как бы всё по-отдельности работает.

библиотека, которая сломалась от обновления работает? откуда ты это знаешь, если тестов на неё у тебя нет, а код её в проекте есть?

докер как раз для поделок и предназначен. тестирование гуйни тем же догтейлом - тот еще адок, в любом случае, поднятие виртуалки и её гашение после тестов на его фоне покажется легкой прогулкой

чем натяпляпать пару тестов - лучше вообще не тестировать, не будешь лишних иллюзий питать

wat? Офигенная логика — «если тесты покрывают не всё значит они не нужны». На всё остальное тоже никакого желания отвечать, сорри. «нефиг пользоваться непонятно чем», пфф... У тебя здравый смысл с best practices перемежается какими-то странными домыслами. Как вы линуксом-то пользуетесь если он весьма хреново тестами покрыт. Ой, wait, зачем я это сказал :)

Ну что-ж, хотя бы буду знать как выглядит мир глазами тестировщиков.

один в треде про юнит-тесты призывает не мокать ФС

Юнит-тестировать функции работы с ФС тоже на mock-ФС?

что с тобой сделал русский рок, парень

так недолго в модераторах, а уже шланг

Как такое тестировать, держать вместе с тестами эталонные файлы?
Создавать временные файлы силами тестов?

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

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

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

Офигенная логика — «если тесты покрывают не всё значит они не нужны»

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

«нефиг пользоваться непонятно чем», пфф

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

Как вы линуксом-то пользуетесь если он весьма хреново тестами покрыт

в продакшне - RHELом, которому можно хотя бы претензии предъявлять, дома - макосью. мне норм.

Ну ты понел, да?

Ты на вопрос-то ответь. А то сначала

вострег> файлы тянут за собой время на их создание, лишние зависимости в тестах, возможные баги с ФС, etc. поэтому в юнит-тестах они, как и работа с БД, эмулируются

и ВЕЗАПНО шлангом оказываюсь я.

дома - макосью. мне норм.

Бгг.

Ты на вопрос-то ответь

дык отвечал уже. тесты на взаимодействие конкретного модуля работы с ФС бывают двух видов - проверить возможность чтения-записи в конкретную ФС (тч по всем понятиям они интеграционные) либо работа с ФС предполагает сложную логику вроде работы с ФС на более низком уровне, где очевидно логика «ни капли в БД ни сантиметра из ФС» не работает.

ни капли в БД ни сантиметра из ФС

Вот не мог не добавить маководческих комплексов в ответ на технический вопрос.

Я как-то для интеграции с внешним сервисом писал по документации апи собственный сервак для тестов.

Это кстати тупик. Почему просто не повызывать свои функции с нужными параметрами как будто они пришли из внешнего сервиса?

Это были интеграционные тесты, надо было проверить серии запросов и нужно было состояние, имитирующее бд.

Дроби функции на более мелкие, используй мутабельность как можно реже.

Это неправильно. Правильно вот так:

Первая функция парсит дирректорию Вторая функция ищет в распарсеном Третья функция выполняет манипуляции

Вот это уже можно тестировать.

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

хоть ты и норкоман, но тут подписуюсь под кажидым словом

Ты же четыре месяца назад ушёл, громко хлопнув дверью.

Его заставили вернуться.

А потом он окажется внебрачным сыном макскома? https://www.youtube.com/watch?v=-6u1c8tpGEE

</offtopic>

С дробностью функций там в порядке, мне представления о механике самих тестов не хватает. Вот сейчас уяснил, что пробовать что-то не раскурив про mock было неправильно. Ну и нужно сразу переходить на pytest походу.

файлы тянут за собой время на их создание, возможные баги с ФC

tmpfs? не, не слышал