Или у вас god object и все намешано в одну кучу?

Или у нас Си, со static-функциями вместо приватных членов.

Или у нас программа на Си++, которая делает некоторые вычисления. В принципе да, можно выделить вычисления из приватных методов в отдельные классы, определить для них API и тестировать. Но если эти классы больше нигде не нужны, это только раздует код без прибавок в ясности для нового читателя.

Почему возникает такая потребность?

Возвращая вопрос, а про тестирование чего (и на каких языках) говоришь ты?

Так а юнит-тесты тут при чем? Они для фиксации семантики служат

А ты точно не про контракты говоришь?

Но если эти классы больше нигде не нужны

Если они нигде заведомо не будут нужны, то почему нельзя ограничиться тестированием публичного апи?

Возвращая вопрос, а про тестирование чего (и на каких языках) говоришь ты?

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

А ты точно не про контракты говоришь?

Точно. Контракты ничего не фиксируют, они нужны для того, чтобы ошибка выстреливала по месту возникновения, а не улетала в далекие дали. При этом они не гарантируют, что если вы код поменяете, то описанные ими инварианты останутся нетронутыми.

потому что тестируется всегда поток управления, а не код (чего многие не понимают).

Самое забавное наблюдать как подобный контингент начинает дробить одну ф-ю на несколько, чтобы типа «заменить 2^n путей на 2*n». Убивал бы за такое.

Если они нигде заведомо не будут нужны, то почему нельзя ограничиться тестированием публичного апи?

Видимо, я не понятно выразился. Сейчас опишу пример.

Допустим, если модуль (класс), который что-то там считает. В вычислениях ему нужны n-ные числа Фибоначчи. Если не нужно итерироваться по этим числам, а разово нужно одно-два числа, логично вынести их вычисление в отдельную функцию. Ну и тестировать эту функцию удобнее отдельно.

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

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

Ну в данном случае как раз вполне осмысленно выносить, то есть семантически это вполне осмысленная отдельная задача и вполне соответствует общим принципам проектирования.

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

Спасибо, про tdd сейчас уже поздно рассказывать, это легаси. И поскольку за выделенное время явно невозможно покрыть тестами всё, у меня вопрос, как ставится целеполагание для тестера. у меня оно пока сформулировано в стиле «от забора и до обеда» и чтобы степень покрытия была не менее, чем X. Поскольку сейчас она около нуля, а X не так уж велик, я так понимаю, можно снять сливки, сделав самое простое, но качество этой работы будет сомнительным.

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

Хотя когда я подавал туда, я серьёзно к этому не относился и ни на что особо не рассчитывал.

как ставится целеполагание для тестера

Ты же вроде спрашивал про юнит-тесты? Их пишут разработчики, а не тестеры.

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

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

представь виртуально что тебе надо переписать вооон тот внутренний метод у тебя не возникает подсознательное чувство опаски? «я бы лучше это не трогал... ведь работает, а то что работает - не надо трогать!»

если не возникает - все впорядке

Не правильно ставишь целепологание.

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

Степень покрытия очень тупая метрика, она хороша только когда более 80% кода покрыты тестами. Иначе она не показывает ничего полезного кроме уныния и тоски.

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

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

Степень покрытия очень тупая метрика, она хороша только когда более 80% кода покрыты тестами.

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

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

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

Ты же вроде спрашивал про юнит-тесты? Их пишут разработчики, а не тестеры.

4.2 писать их может абсолютно кто угодно. вопрос разделения ролей в конкретной команде

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

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

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

требования к апи модулей (юниты - это что-то из HoMM)

Нет, модули и юниты - это семантически разные вещи.

растут из требований к приложению и структуры системы

причем «структуры системы» - в первую очередь.

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

куча плохо протестированного говна

будет в любом случае если тестировать абы как

Лучше, чтобы часть системы была протестирована хорошо, а остальная - совсем никак, чем вся система была протестирована кое-как.

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

Это не я ставлю целеполагание. Критерий спускают сверху. Моя задача - удовлетворить эту цифру и при этом сделать это наиболее полезным для продукта образом. Требований к отдельным модулям нет. Есть куча старого кода с комментариями, часть из которых соответствует действительности. Разработчиков этого кода нет, хотя нынешняя команда что-то понимает в нём. Но не полезешь же с каждым вопросом к команде - это увеличит фактические трудозатраты. Лог багов какой-то есть. Есть некоторое количество интеграционных тестов. Есть руководство пользователя. Вот исходная информация, которой я располагаю.

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

Вообще, если гранулярность нормальная, то для любого модуля тесты должно быть можно написать «за присест». Я бы в этом случае выбрал те модули, что находятся в активной разработке, а также те, что написаны недавно (т.к. их вероятность изменения выше) - и начал бы тестировать их (полностью, сперва один, потом второй, потом третий, к следующему переходим когда закончили с предыдущим). Почему выбираются именно эти (активные)? Потому что пользы от их тестирования больше. Если у нас какойто модуль написан 10 лет назад, с тех пор не менялся и еще столько же не будет - то, ну, его тестирование можно на эти десять лет спокойно и отложить, ничего не потеряв.

просто требования к оценке рисков выше.

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

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

вот это - очень оптимистичное допущение

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

ага, а потом на интеграции случится bigbadaboom, потому что старые модули с новыми не очень-то совместимы

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

good practice - не оценивать риски в одно лицо, как минимум - бизнес-аналитик либо продукт овнер, тестировщик, знакомый с проектом, девелоперы. роль ТСа в данном случае просто наблюдать и запоминать.

good practice - не оценивать риски в одно лицо, как минимум - бизнес-аналитик либо продукт овнер, тестировщик, знакомый с проектом, девелоперы. роль ТСа в данном случае просто наблюдать и запоминать.

То есть в итоге ответ на его вопрос «как и в каком порядке что делать?» - «спроси у того, кто знает проект». Лучше, чем тс, и точно лучше, чем мы.

ага, а потом на интеграции случится bigbadaboom, потому что старые модули с новыми не очень-то совместимы

Но они же сейчас работают? А ТС их не переписывает, только тесты добавляет.

вот это - очень оптимистичное допущение

Конечно. Если есть что-то крупное из активного - тогда уже бить на сабтаски. Но в любом случае это к знающим проект товарищам. «для чего и какие тесты мне написать сегодня, чтобы вам было полезно уже вот прям завтра?»

ага, а потом на интеграции случится bigbadaboom

Но об этом меня никто не спросит. Я вообще не сторонник юнит тестов, но моё дело - исполнять команды.

ну это очевидно было. вопрос в том, чтобы организовать «спроси у того, кто знает проект» не в виде балагана или спросить у кого-то одного, а взять ту же матрицу из PRISM (которая Technical vs Business Risk), в которой по одномерным оценкам (PO говорит что это важно, девелопер говорит что это невозможно) расставить риски.

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

Но они же сейчас работают? А ТС их не переписывает, только тесты добавляет.

обычно это бывает так: сидит ТС, покрывает тестами неизвестный ему модуль, натыкается на непонятки и идет к допустим QA, у которого спрашивает «дорогой ты мой человек, у нас нигде не описано, а какая реакция должна быть на вот такое значение на входе?» QA с потолка придумывает отмазку, а сам со словами «ай шайтан, забыль-забыль», говнякает интеграционный тест для такого кейса. вариант «интеграционные тесты работают ну и пес с ним» прокатывает очень редко

good practice - не оценивать риски в одно лицо, как минимум - бизнес-аналитик либо продукт овнер, тестировщик, знакомый с проектом, девелоперы. роль ТСа в данном случае просто наблюдать и запоминать.

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

анкета - так себе вариант. собери их в одном месте, в процессе обсуждения 100% вылезут кейсы, о которых раньше никто не задумывался

Спасибо за совет.

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

Однако, к unit тестам я применил бы те же самые подходы - магистральные кейсы в первую очередь. Самые частоиспользуемые модули в первую очередь. Плюс о5 же багфикс.

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

юнит-тест, это вид теста, а функциональный - это цель теста. Нет?

тот неловкий момент, когда спрашивающий это понимает, а советчики - нет :) только юнит (как и интеграционный, системный, etc) - это уровень тестирования, а функциональный (нефункциональный, тест изменений) - вид. единственное что - путаница, которую вносит перевод разделения unit/component на русский - и то и другое переводят как «юнит-тест» и получается бардак с понятиями

А в том, что юнит тесты вполне могут быть одновременно и функциональными тестами.

в 90% случаев юнит-тесты функциональными и являются (одновременно проводя тестирование изменений)

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

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

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

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

Функциональные - через интерфейсы приложения

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

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

NO

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

в вашем примере ваша задача «доработать систему юнит-тестов» будет звучать как

Организовать фреймворк для выполнения тестов

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

Определить требования к тестируемой системе и её отдельным модулям

На основании требований покрыть функциональными модульными тестами все выделенные модули

Организовать фреймворк для генерации отчетов о тестировании

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

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

Ну, в свою защиту могу сказать что ~70% тестирования на проектах где я участвовал это автоматизированное тестирование, так что с практической точки зрения кое какой опыт имеется :)

А за ссылки спасибо, даже не знал что сия терминология кем то стандартизированна.

одна поправка к ним: в официальной на данный момент документации unit и component являются синонимами, соответственно разделения модульных тестов на unit и component, как в примере выше, нет. возможно, в новой редакции стандарта unit тесты вынесут в отдельный уровень, но не факт

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

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

Фреймворк (lisp-unit) есть с определением покрытия (sb-cover) и генерацией отчётов, нет только экспорта данных для начальства, но это не суть.

Остаётся: разобрать на минимальные модули (я бы сказал, идентифицировать те модули, которые уже являются отдельными. Ничего делать с кодом я не могу).

Определить требования (ха-ха, почитать/погонять код и понять, что имел в виду разработчик. Ну ладно).

Покрыть функциональными модульными тестами - так точно.

В общем, гранд мерси! Наверное, тему можно на этом закрывать.

возвращаясь к вопросу «что почитать». если сформулированная мной выше задача звучит правильно - читай библию

http://www.amazon.com/Foundations-Software-Testing-ISTQB-Certification/dp/184... - в свободном доступе куча

http://www.amazon.com/Software-Test-Engineers-Handbook-2nd/dp/1937538443/ref=... - в бесплатном виде не видел, но есть https://ru.scribd.com/read/264126959/The-Software-Test-Engineer-s-Handbook-2n... с 14-дневным триалом.

Вопросы терминологии, методологий, написания тестов - в основном первая. Оценки рисков, определения требований и advanced написания тестов - вторая. Экзаменационные вопросы читать по желанию

Спасибо!