простите, но Вы забыли постусловие с переполнением и тест на него. а еще тесты бы граничными условиями дополнить, чего не написано даже в ТЗ (а должно быть, как программа себя ведет в граничных случаях?). sum(-MAX_INT, -MAX_INT) - это переполнение или успех? а в остальном - все отлично!
Но все же пирамида тестирования утверждает, что тест должен быть реализован на самом нижнем уровне, на котором это возможно. (Иначе пирамиды не выйдет, очевидно же?)
Пример. Валидация введенной суммы перевода.
Можно проверять прям от UI через сервер и до появления красной картинки обратно на UI. Получится сложный, медленный, дорогой, хрупкий e2e-тест, который тестирует поведение.
Но самый ли нижний это из возможных уровней, где проводится валидация?
Нет, конечно!
Мы можем убрать UI и проверять, допустим, что вход в функцию валидации какого-то значения, возвращает или не возвращает ошибку (которая потом бы в UI превратился в красную картинку). Так мы опустили проверки на уровень ниже. Проверяется ли при этом нужное поведение? Да, если к нему добавить 2 интеграционных теста, которые проверят, что значение из UI корректно в функцию записывается, а её возвращаемое значение корректно в UI устанавливается.
Что мы получили? Интеграция проверена 1 раз. Валидация введенного знания - 1 раз. Многократного покрытия нет.
Что касается TDD, то, наверное, Вы правы, что сначала будет написан один высокоуровневый e2e тест. Но ничто не мешает Вам на стадии рефакторинга рефакторить не только код, но и тест (или мешает? вопрос автору статьи, кстати @iv660 подразумевает ли рефакторинг и рефакторинг ранее написанного теста? ), разбивая 1 большой тест на несколько меньших, опуская все возможные проверки на более низкие уровни. Так вы избежите многократного тестирования и получите надежные, дешевые, быстрые тесты, которые не боятся рефакторинга, ибо каждый ваш тест будет соответствовать тому уровню, на котором реализовано соответствующее поведение.
А может, лучше "суп отдельно, а мухи отдельно" - в смысле спецификация отдельно, а проверка ее отдельно? Потому что объективно нужны эти вещи в разные моменты времени: спецификация - в процессе создания программы, а тесты - уже на этапе контроля, когда программа создана.
2 момента:
Тесты нужны ДО создания программы и ВО ВРЕМЯ её создания тоже. Об этом вся статья про TDD, в комментах к которой мы общаемся (например, пп.1,6,7). Об этом же и Ваш пункт про СПЕЦИФИКАЦИЮ, который мы сейчас обсуждаем. СПЕЦИФИКАЦИЯ подразумевает, что она должна быть написана ДО. Значит, и тесты должны быть написаны ДО. Также Вы выше пишите, что тесты нужны только на стадии ФИНАЛЬНОГО контроля. Но вот теория менеджмента подразумевает, что контроль бывает не только финальный. Он еще бывает входящий (ДО начала выполнения задачи, т.е.разработки программы), промежуточный и переодический (последние 2 - ВО ВРЕМЯ разработки программы). Отсюда снова следует, что тесты должны быть созданы как минимум ДО начала работы программы, если мы их хотим использовать для входного контроля, или ВО ВРЕМЯ, если хотим использовать промежуточный и/или переодический. Автору в п.4 и отдельным пунктом можно добавить про типы контроля и как TDD помогает про них не забывать...
Конечно нужно разделять! Разделение мух от котлет выглядит так: фиксируем мы требования и поведение через написание теста, а контролируем потом через его исполнение. Вас не устраивает такое разделение?
Код по сравнению с текстом слишком многословен, то есть имеет больший объем, причем объем кода тестов (в строках и знаках) обычно в разы больше объема покрываемого ими кода приложения (правда сложность - цикломатическая и т.п. - кода тестов обычно меньше). В коде, опять же, надо уделять внимание соблюдению церимониалов используемых языков/библиотек/фреймворков (boilerplate),. Код, даже "самодокументируемый", труднее читать, чем текстовое описание, наконец.
Ниже в этой же ветке уже ответили, что это не всегда так. Я лишь добавлю, что перечисленные Вами "недостатки" давно придумано как нивелировать и устранять. Учитывая это я бы даже сказал, что запись спецификации в виде тестов ДОВОЛЬНО ЧАСТО получается даже дешевле и проще, чем обычным человеческим текстом. Отсюда мы возвращаемся к тезису про более дешевую сумму записи спецификации и её автоматизации и получаем, что автотесты становятся практически самым дешевым и эффективным вариантом, как бы со стороны не казалось иначе. Такой вот парадокс, да.
А она точно нужна, эта автоматизация?
Про это п.4. И мои комментарии выше. Я тоже LLM не использовал для генерации тестов, но прекрасно знаю некоторые своды правил, которые позволяют сделать так, что требования из ТЗ, записанные в виде кода теста, получаются проще, чем в тексте самого ТЗ. Возможно, Вы умеете писать ТЗ круче наших аналитиков (в этот вопрос я с вами в дискуссию вступать не стану).
А забыли про овраги: в процессе начальной разработки - всего приложения или какой-то отноительно самостоятельной его функции, проводимом без предварительного детального проектирования (то есть - в обычном практическом случае) меняться может многое, почти всё. В том числе и поведение, и разбиение его на единицы. И уж всяко - интерфейсы, через которые взаимодействуют модули. И чем менее тривильна разрабатываемая программа, тем чаще такие изменения происходят.
Ну, я же не зря Вам целую книгу порекомендовал, наверное? Вот Вы спорите даже не прочитав, похоже. Собственно, как и всю статью... че уж я про книгу-то сетую...
Пожалуй, на этом я остановлюсь, на дальнейшие Ваши комментарии отвечать не стану. Спасибо Вам за содержательную дискуссию.
Ну, Вы сами написали, что TDD можно писать с любыми тестами. Но пирамида тестирования утверждает, что модульных (юнитов) должно быть больше всего. Поэтому замените в названии статьи модульные тесты на TDD - логическая цепочка не нарушится, смысл не поменяется.
Нет, не кажется. Это лишь частично спецификация. Второй частью – это автоматизация проверки соответствия результата этой спецификации. Т.е. заменять тесты только спецификацией – в корне неверно. Вы еще обязаны для полного замещения организовать автоматизацию на другой тип написания спецификации. Если другие типы написания спецификации и будут проще, то вот их автоматизация – навряд ли. Соответственно и сумма спецификации в другом типе и её автоматизации выйдет дороже, чем тесты.
Проблема изменения тестов при изменении внутренней реализации давно решена: тестируются не детали внутренней реализации, а единица поведения. Подробнее в книге Хорикова про модульное тестирование.
Пирамида тестирования утверждает, что каждая единица поведения должна быть проверена ровно 1 раз и на том самом нижнем уровне, на котором её можно проверить. Не все можно проверить на самом нижнем уровне – уровне модульных тестов без интеграций. Но если уж вы проверили что-то на более низком уровне, то на более высоком дублирующих тестов быть не должно, это же очевидно.
Как результат, ситуация "функционал одного и того же компонента покрывается многократно" невозможна. Более того, если тесты пишутся именно на поведение, а не на детали внутренней реализации, то проблем с рефакторингом не будет. Почему, очень хорошо объяснено в книге Хорикова про модульное тестирование.
Спасибо за статью. Лучшее описание типов, что я на данный момент встречал. Хотя я и не читал-то слишком больше, чем академических учебников, где все описывается сухо и на советских примерах (ой, кажется, у Вас тоже на них же :)
С нетерпением ждем пост про грамотную расстановку людей и соответствующие ссылки.
Это может быть человек с любым преобладающим типом. Даже "избегательный" – для него маленький стартап – это возможность делать еще меньше, другие работают, а он отдыхает. Внезапно.
Не совсем понимаю, как верифицированный телефон связан с неверефицированным почтовым адресом? Тем более для Минцифры. Ей надо было запросить у mail.ru верификацию телефона для соответствующего почтового адреса? А это законно?
Все остальное официальным ответом не является. Бабушки-операционистки на почтовом ящике об этом знают, а потому и не отвечают СМИ.
Я далёк от СМИ, но очень удивлён, что СМИ готовы публиковать неофициальные ответы бабушек-операционисток (по сути без проверки) только для того, чтобы опубликовать новость быстрее остальных.
Подождите, но почему Вы не направили обращение по указанной Вам ссылке?
Уже лет 8 точно, как гос.органы РФ принимают обращения на специальных страничках своих сайтов, а не по e-mail. Причина проста: e-mail анонимен, а обращения у нас в стране принимаются только не анонимные.
Вот сейчас введут закон о регистрации имейлов только по паспорту и обязательном подтверждении имеющихся в н-ный срок и сможете писать с подтвержденных госуслугами ящиков :)
Да и функциональная парадигма даже старше, чем ООП...
Сначала придумали функциональный подход и только потом, что-то в нем не устроило и пришлось до ООП расширяться...
Кстати, ООП не отрицает функциональной парадигмы. Все так же можно создавать объекты, объединяющие данные и функции вместе, при этом функции в таких объектах будут pure, объекты не будут иметь сайд-эффектов и состояния и т.д.
Там есть второй более важный принцип, про который, похоже, и Вы забыли...
Принцип этот делает этот вопрос и всю статью далее просто бессмысленной: "Но вопрос в другом - можно ли с ним работать? Понять, поправить, развить, не впадая в экзистенциальный кризис."
Принцип называется Open/Closed и сводится он к тому, что ранее написанное уже никогда не должно "правиться" и даже "пониматься". Если следовать этому принципу, то необходимость в этом пропадает, можно, не изменяя ни буквы в старом коде, расширять его под новое поведение. А если это невозможно (чего в реальности не бывает), то писать рядом новый код, если написание нового будет дешевле расширения старого... Таким образом достигается развитие без "экзистенциального кризиса".
А самое прекрасное – что чек-лист теперь уже можно и пытаться автоматизировать, шаг за шагом. Автоматизация "с нуля" всего процесса была бы неподъемной задачей, просто потому, что процесс не был формализован и описан. Теперь он формализован, описан, закреплен "на бумаге" – чего бы не взяться за автоматизацию с уже созданным на 80% по пунктам планом? :) Молодцы! Действительно полезная вещь!
Подскажите, пожалуйста, а зачем в iOS реализовывать свои запросы с помощью curl? В инструкции по КриптоПРО нет ничего про это. Такое ощущение, что библиотека КриптоПРО подменяет системный уровень, аналогично тому, как это устроено на Android.
простите, но Вы забыли постусловие с переполнением и тест на него.
а еще тесты бы граничными условиями дополнить, чего не написано даже в ТЗ (а должно быть, как программа себя ведет в граничных случаях?).
sum(-MAX_INT, -MAX_INT)- это переполнение или успех?а в остальном - все отлично!
Вы правы, подходов много.
Но все же пирамида тестирования утверждает, что тест должен быть реализован на самом нижнем уровне, на котором это возможно. (Иначе пирамиды не выйдет, очевидно же?)
Пример. Валидация введенной суммы перевода.
Можно проверять прям от UI через сервер и до появления красной картинки обратно на UI. Получится сложный, медленный, дорогой, хрупкий e2e-тест, который тестирует поведение.
Но самый ли нижний это из возможных уровней, где проводится валидация?
Нет, конечно!
Мы можем убрать UI и проверять, допустим, что вход в функцию валидации какого-то значения, возвращает или не возвращает ошибку (которая потом бы в UI превратился в красную картинку). Так мы опустили проверки на уровень ниже. Проверяется ли при этом нужное поведение? Да, если к нему добавить 2 интеграционных теста, которые проверят, что значение из UI корректно в функцию записывается, а её возвращаемое значение корректно в UI устанавливается.
Что мы получили? Интеграция проверена 1 раз. Валидация введенного знания - 1 раз. Многократного покрытия нет.
Что касается TDD, то, наверное, Вы правы, что сначала будет написан один высокоуровневый e2e тест. Но ничто не мешает Вам на стадии рефакторинга рефакторить не только код, но и тест (или мешает? вопрос автору статьи, кстати @iv660 подразумевает ли рефакторинг и рефакторинг ранее написанного теста? ), разбивая 1 большой тест на несколько меньших, опуская все возможные проверки на более низкие уровни. Так вы избежите многократного тестирования и получите надежные, дешевые, быстрые тесты, которые не боятся рефакторинга, ибо каждый ваш тест будет соответствовать тому уровню, на котором реализовано соответствующее поведение.
У нас вроде работает \Разведенные в сторону руки/
2 момента:
Тесты нужны ДО создания программы и ВО ВРЕМЯ её создания тоже. Об этом вся статья про TDD, в комментах к которой мы общаемся (например, пп.1,6,7). Об этом же и Ваш пункт про СПЕЦИФИКАЦИЮ, который мы сейчас обсуждаем. СПЕЦИФИКАЦИЯ подразумевает, что она должна быть написана ДО. Значит, и тесты должны быть написаны ДО.
Также Вы выше пишите, что тесты нужны только на стадии ФИНАЛЬНОГО контроля. Но вот теория менеджмента подразумевает, что контроль бывает не только финальный. Он еще бывает входящий (ДО начала выполнения задачи, т.е.разработки программы), промежуточный и переодический (последние 2 - ВО ВРЕМЯ разработки программы).
Отсюда снова следует, что тесты должны быть созданы как минимум ДО начала работы программы, если мы их хотим использовать для входного контроля, или ВО ВРЕМЯ, если хотим использовать промежуточный и/или переодический.
Автору в п.4 и отдельным пунктом можно добавить про типы контроля и как TDD помогает про них не забывать...
Конечно нужно разделять!
Разделение мух от котлет выглядит так: фиксируем мы требования и поведение через написание теста, а контролируем потом через его исполнение. Вас не устраивает такое разделение?
Ниже в этой же ветке уже ответили, что это не всегда так. Я лишь добавлю, что перечисленные Вами "недостатки" давно придумано как нивелировать и устранять. Учитывая это я бы даже сказал, что запись спецификации в виде тестов ДОВОЛЬНО ЧАСТО получается даже дешевле и проще, чем обычным человеческим текстом.
Отсюда мы возвращаемся к тезису про более дешевую сумму записи спецификации и её автоматизации и получаем, что автотесты становятся практически самым дешевым и эффективным вариантом, как бы со стороны не казалось иначе. Такой вот парадокс, да.
Про это п.4. И мои комментарии выше. Я тоже LLM не использовал для генерации тестов, но прекрасно знаю некоторые своды правил, которые позволяют сделать так, что требования из ТЗ, записанные в виде кода теста, получаются проще, чем в тексте самого ТЗ. Возможно, Вы умеете писать ТЗ круче наших аналитиков (в этот вопрос я с вами в дискуссию вступать не стану).
Ну, я же не зря Вам целую книгу порекомендовал, наверное? Вот Вы спорите даже не прочитав, похоже. Собственно, как и всю статью... че уж я про книгу-то сетую...
Пожалуй, на этом я остановлюсь, на дальнейшие Ваши комментарии отвечать не стану. Спасибо Вам за содержательную дискуссию.
Ну, Вы сами написали, что TDD можно писать с любыми тестами. Но пирамида тестирования утверждает, что модульных (юнитов) должно быть больше всего. Поэтому замените в названии статьи модульные тесты на TDD - логическая цепочка не нарушится, смысл не поменяется.
Нет, не кажется. Это лишь частично спецификация. Второй частью – это автоматизация проверки соответствия результата этой спецификации. Т.е. заменять тесты только спецификацией – в корне неверно. Вы еще обязаны для полного замещения организовать автоматизацию на другой тип написания спецификации. Если другие типы написания спецификации и будут проще, то вот их автоматизация – навряд ли. Соответственно и сумма спецификации в другом типе и её автоматизации выйдет дороже, чем тесты.
Проблема изменения тестов при изменении внутренней реализации давно решена: тестируются не детали внутренней реализации, а единица поведения. Подробнее в книге Хорикова про модульное тестирование.
Пирамида тестирования утверждает, что каждая единица поведения должна быть проверена ровно 1 раз и на том самом нижнем уровне, на котором её можно проверить. Не все можно проверить на самом нижнем уровне – уровне модульных тестов без интеграций. Но если уж вы проверили что-то на более низком уровне, то на более высоком дублирующих тестов быть не должно, это же очевидно.
Как результат, ситуация "функционал одного и того же компонента покрывается многократно" невозможна. Более того, если тесты пишутся именно на поведение, а не на детали внутренней реализации, то проблем с рефакторингом не будет. Почему, очень хорошо объяснено в книге Хорикова про модульное тестирование.
Для конкретизации п.5 вот даже целую детальную статейку набросали, почему так выходит...
Спасибо за статью. Лучшее описание типов, что я на данный момент встречал. Хотя я и не читал-то слишком больше, чем академических учебников, где все описывается сухо и на советских примерах (ой, кажется, у Вас тоже на них же :)
С нетерпением ждем пост про грамотную расстановку людей и соответствующие ссылки.
Это может быть человек с любым преобладающим типом. Даже "избегательный" – для него маленький стартап – это возможность делать еще меньше, другие работают, а он отдыхает. Внезапно.
Не совсем понимаю, как верифицированный телефон связан с неверефицированным почтовым адресом? Тем более для Минцифры. Ей надо было запросить у mail.ru верификацию телефона для соответствующего почтового адреса? А это законно?
Все верно. Месяц на официальный ответ.
Все остальное официальным ответом не является. Бабушки-операционистки на почтовом ящике об этом знают, а потому и не отвечают СМИ.
Я далёк от СМИ, но очень удивлён, что СМИ готовы публиковать неофициальные ответы бабушек-операционисток (по сути без проверки) только для того, чтобы опубликовать новость быстрее остальных.
Так и живем...
Подождите, но почему Вы не направили обращение по указанной Вам ссылке?
Уже лет 8 точно, как гос.органы РФ принимают обращения на специальных страничках своих сайтов, а не по e-mail. Причина проста: e-mail анонимен, а обращения у нас в стране принимаются только не анонимные.
Вот сейчас введут закон о регистрации имейлов только по паспорту и обязательном подтверждении имеющихся в н-ный срок и сможете писать с подтвержденных госуслугами ящиков :)
А дядя Боб сам приводил формулы – зачем повторяться?
Очень странно, что их никто не считает... Хотя на одном из последних мобиусов показывали попытки подсчета...
Все эти паттерны уже реализованы в iOS и очень часто встречаются:
Chain of Responsibility -> Responder Chain;
Mediator, Strategy -> UIViewController и т.д.;
Composite - это UIView, сабвьюхи и контроллеры с их деревьями;
фабрики, билдеры – можно смотреть на сториборды, нибы и конструкторы различных форм и видов различных классов, не только вьюх, контроллеров;
...
Лучше бы проанализировали, как шаблоны у Эпла реализованы, как используются, есть ли отличия, почему, что из этого следует?
Не сочиняйте своего, учитесь у лучших! Только так можно превзойти лучших. А если будет сочинить, максимум добьетесь того же...
Ждем переработку Вашего цикла.
Да и функциональная парадигма даже старше, чем ООП...
Сначала придумали функциональный подход и только потом, что-то в нем не устроило и пришлось до ООП расширяться...
Кстати, ООП не отрицает функциональной парадигмы. Все так же можно создавать объекты, объединяющие данные и функции вместе, при этом функции в таких объектах будут pure, объекты не будут иметь сайд-эффектов и состояния и т.д.
Вот тут подробнее.
.
а у меня не получалось такого руководителя удерживать рядом более 5 лет... в итоге более 5 рядом не соберешь никогда.
есть советы?
Там есть второй более важный принцип, про который, похоже, и Вы забыли...
Принцип этот делает этот вопрос и всю статью далее просто бессмысленной: "Но вопрос в другом - можно ли с ним работать? Понять, поправить, развить, не впадая в экзистенциальный кризис."
Принцип называется Open/Closed и сводится он к тому, что ранее написанное уже никогда не должно "правиться" и даже "пониматься". Если следовать этому принципу, то необходимость в этом пропадает, можно, не изменяя ни буквы в старом коде, расширять его под новое поведение. А если это невозможно (чего в реальности не бывает), то писать рядом новый код, если написание нового будет дешевле расширения старого... Таким образом достигается развитие без "экзистенциального кризиса".
Вот если бы новичкам об этом написали...
А самое прекрасное – что чек-лист теперь уже можно и пытаться автоматизировать, шаг за шагом. Автоматизация "с нуля" всего процесса была бы неподъемной задачей, просто потому, что процесс не был формализован и описан. Теперь он формализован, описан, закреплен "на бумаге" – чего бы не взяться за автоматизацию с уже созданным на 80% по пунктам планом? :)
Молодцы! Действительно полезная вещь!
Подскажите, пожалуйста, а зачем в iOS реализовывать свои запросы с помощью curl? В инструкции по КриптоПРО нет ничего про это. Такое ощущение, что библиотека КриптоПРО подменяет системный уровень, аналогично тому, как это устроено на Android.