Здравствуйте, Ikemefula, Вы писали:
I>Наоборот, изначально было про юнит-тест, а Pzz поменял до "тест"
Я сознательно написал "тест", потому что мне все равно, юнит он тест, интеграционный или наушахстоятельный. Лишь бы его прогоняли перед выпуском релиза.
Здравствуйте, Ikemefula, Вы писали:
I>Необходимости, конечно же нет. Но факт в том, что как ни крути, юнит-тесты будут сильно дискретными.
И даже при этом они могут быть достаточными для обеспечения приемлимого, если не исчерпывающего покрытия
I>Потому гарантировать срабатывание до факапа попросту бессмысленно.
Ага, потому что наличие юнит тестов позволяет вообще избежать появления такого факапа
Здравствуйте, Ikemefula, Вы писали:
I>Ни классы эквивалентности, ни вообще вся теория тестирования никак не гарантируют, что ты найдешь любую регрессию.
Юнит-тесты, на минутку так, помогают писать код так, чтобы минимизировать возможность регрессии в первую очередь.
I>Потому человек, который утверждает обратное, просто понторез. Классы эквивалентности это про экономическую целесообразность тестирования, а не 100% покрытие.
У тебя, естественно, есть математическое доказательство? Пока ничего, кроме красивых слов, не видно.
Здравствуйте, itslave, Вы писали:
I>>Годится. Щас проверим. Дано — функция, которая суммирует два числа. Список тестов в студию. I>Озвучь список acceptance criterias: минимальные-максимальные числа, поведение при переполнении, и остальные специальные случаи.
Здравствуйте, Ikemefula, Вы писали:
I>>Озвучь список acceptance criterias: минимальные-максимальные числа, поведение при переполнении, и остальные специальные случаи.
I>То есть, сделать твою работу за тебя ?
Юнит-тесты для юнитов пишут программисты, написавшие эти юниты. Это для тебя сюрприз?
Здравствуйте, landerhigh, Вы писали:
I>>>>Ни классы эквивалентности, ни вообще вся теория тестирования никак не гарантируют, что ты найдешь любую регрессию. I>>>Гарантирует.
I>>Годится. Щас проверим. Дано — функция, которая суммирует два числа. Список тестов в студию.
L>Приведи либо код, либо список требований.
Код может быть любым. Мы ведь регрессию детектим ? Представь себе, что джуниор сделал фикс, пусканул тесты, убедился что они зелёные...
Здравствуйте, landerhigh, Вы писали:
I>>То есть, факап уже случился ?
L>Нет. Я, как автор, знаю, что такие входные данные для данного юнита есть факап.
И ты разумеется можешь предусмотреть вообще все возможные случаи ? Ну, например, что завтра твой файл подфиксит джуниор, который проверит только цвет результат.
L>Это неважно. Главная задача юнит-тестов состоит в том, чтобы на самых ранних стадиях проверить, что поведение юнита соответствует ожидаемому.
Не поведение, небольшое количество точечных проверок.
Здравствуйте, Pzz, Вы писали:
I>>Наоборот, изначально было про юнит-тест, а Pzz поменял до "тест"
Pzz>Я сознательно написал "тест", потому что мне все равно, юнит он тест, интеграционный или наушахстоятельный. Лишь бы его прогоняли перед выпуском релиза.
А как ты собираешься укладываться во временные требования ? Ну что бы все тесты выполнялись не бесконечно, а за определенное кличество времени ?
Здравствуйте, landerhigh, Вы писали:
I>>Потому гарантировать срабатывание до факапа попросту бессмысленно.
L>Ага, потому что наличие юнит тестов позволяет вообще избежать появления такого факапа
Снова возвращаемся к тому, с чего начинали. Ты утверждаешь, ни много ни мало, о принципиальной возможности тестировать с помощью юнит-тестов.
Вот странно, ты до сих пор тесты для суммы натуральных чисел не выдал, а утверждаешь, что тестами можно любой факап сбороть.
Здравствуйте, landerhigh, Вы писали:
I>>Ни классы эквивалентности, ни вообще вся теория тестирования никак не гарантируют, что ты найдешь любую регрессию.
L>Юнит-тесты, на минутку так, помогают писать код так, чтобы минимизировать возможность регрессии в первую очередь.
Возможность регрессии минимизируется при помощи
1 проектирование
2 грамотный кодинг
Любые автоматические тесты нужны для проверки заранее определенных точек. Факап, что характерно, не обязан попадать ни в одну из этих точек.
I>>Потому человек, который утверждает обратное, просто понторез. Классы эквивалентности это про экономическую целесообразность тестирования, а не 100% покрытие.
L>У тебя, естественно, есть математическое доказательство? Пока ничего, кроме красивых слов, не видно.
Разумеется. Именно потому я и предлагаю накидать тебе тесты для суммы натуральных чисел.
Здравствуйте, landerhigh, Вы писали:
L>Это неважно. Главная задача юнит-тестов состоит в том, чтобы на самых ранних стадиях проверить, что поведение юнита соответствует ожидаемому.
Не совсем понимаю, чем юнит-тесты помогут при сабже:
был код
int sum(int a, int b)
{
if(!good(a))
throw InvalidArgument();
if(!good(b))
throw InvalidArgument();
return a + b;
}
Покрыт хорошо и замечательно юнит-тестами.
А теперь приходит девелопер с шашкой на коне и изменяет код:
int sum(int a, int b)
{
appendToFile("debug.log", a, b); // Don't forget to remove it before release!!!11111!!11!!
if(!good(a))
throw InvalidArgument();
if(!good(b))
throw InvalidArgument();
return a + b;
}
И что дальше?
Нужна очень серьёзная оргаризация автоматического тестирования — и нагрузочные, и системные, и функциональные тесты должны быть хорошо продуманы. И тут может быть экономический фактор — цена такой системы может быть выше, чем цена таких факапов.
К сожалению, юнит-тесты — не панацея.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, neFormal, Вы писали:
I>>Годится. Щас проверим. Дано — функция, которая суммирует два числа. Список тестов в студию.
F>- проверка валидности аргументов F>- проверка результата и граничных условий на выбранном диапазоне
Проверка валидности аргументов это что за юнит-тест такой ?
Диапазон простой — натуральные числа до 128 разрядов включительно. Где гарантии ?
Здравствуйте, landerhigh, Вы писали:
I>>То есть, сделать твою работу за тебя ?
L>Юнит-тесты для юнитов пишут программисты, написавшие эти юниты. Это для тебя сюрприз?
Это не важно. Регрессия она целиком про человеческий фактор. Об этом Гленфорд Майерс всю книгу талдычит.
Ты в курсе, что люди увольняются, переходят в другие отделы, на другие должности ?
Ты в курсе, что даже в одном проекте нет гарантии, что что один и тот же компонент будет майнтейнить один и тот же девелопер ?
Здравствуйте, Ikemefula, Вы писали:
I>Проверка валидности аргументов это что за юнит-тест такой ?
обычный тест, что с данными можно работать. что они подходят для данной операции.
I>Диапазон простой — натуральные числа до 128 разрядов включительно. Где гарантии ?
Здравствуйте, neFormal, Вы писали:
I>>Проверка валидности аргументов это что за юнит-тест такой ?
F>обычный тест, что с данными можно работать. что они подходят для данной операции.
Покажи на примере:
function sum(a,b) {
return a+b;
}
I>>Диапазон простой — натуральные числа до 128 разрядов включительно. Где гарантии ?
F>а в чём сомнения? интерполяцию отрицаешь?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, itslave, Вы писали:
I>>>Годится. Щас проверим. Дано — функция, которая суммирует два числа. Список тестов в студию. I>>Озвучь список acceptance criterias: минимальные-максимальные числа, поведение при переполнении, и остальные специальные случаи.
I>То есть, сделать твою работу за тебя ?
Слив засчитан.
Здравствуйте, Ikemefula, Вы писали:
I>Код может быть любым. Мы ведь регрессию детектим ? Представь себе, что джуниор сделал фикс, пусканул тесты, убедился что они зелёные...
Если мы говорим про юнит-тестирование — то это white box тесты. С требованием иметь 100% покрытие бизнес логики. Внезапно.
Здравствуйте, Ikemefula, Вы писали:
L>>Приведи либо код, либо список требований.
I>Код может быть любым.
Задам прямой вопрос — ты вообще понимаешь, что такое юнит-тесты? Это не наезд, я всегда спрашиваю, а то куча народу на поверку думают себе разное и в итоге получается раговор доцента с Авасом.
I>Мы ведь регрессию детектим ? Представь себе, что джуниор сделал фикс, пусканул тесты, убедился что они зелёные...
А я не представляю, это вполне нормальный цикл разработки. Сеньер — джуниору — "у нас есть баг, когда подаются данные типа А, происходит бум предпололжительно в модуле Б. Пофикси.", хотя чаще всего "наши юниты не реализуют поддержку ситуации C, и посему бросают исключение. Нужно реализовать поддержку и убрать исключение".
Джуниор первым делом делает что? Правильно, пишет тест, воспроизводящий проблему. Затем идентифицирует провинившийся модуль и пишет минимально возможный тест, воспроизводящий проблему. Затем фиксит проблему. Это должно сделать означенные два или сколько он там нарисовал тестов зелеными. Затем он идет на ревью, где ему сеньер и говорит — в процессе фикса ты написал 150 строк нового кода и придумал два новых класса. Где юнит-тесты для них? Итерация повторяется.
В результате — есть фикс, есть юнит-тесты, верифицирующие фикс. Есть лучший код. Все щасливы, кроме тестеров.
