![[Test]
public void ld_Getter_Returns_ld()
var sut = new PropertyBag(); sut.ld = 42;
var result = sut.ld; Assert.AreEqual(result, 42)
у/Ь/Х у / У/>'7 Л
риЬПс Ргоре11уВад //ип1еБ1ес1 риЬПс ¡п1 \6 {деЬвеЬ} }
У *'/У/1+7/}
Дэйв с точностью до минуты помнил момент, когда ему стало плевать.](https://img2.joyreactor.cc/pics/post/full/it-юмор-geek-комикс-8289008.jpeg "it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,комикс")
- юнит чего ? *пуш в прод
19.01.2024, 19:36
Есть такая очешуенная книга, и в ней сказано:
-Тестируется изменение публично доступного состояния с какой-то внутренней логикой. DTO-шки тестить смысла нет.
-Тестируется факт вызова методов сервисов что меняют состояние этих сервисов. Методы сервисов которые что-то возвращщают (get-методы) лучше не тестировать а мокать.
- В некоторых случаях надо тестировать последовательность вызовов методов для недопущщения определенных багов
Это сильно упрощщало написание юнит-тестов на проэкте. Рекомендую к прочтению
-Тестируется изменение публично доступного состояния с какой-то внутренней логикой. DTO-шки тестить смысла нет.
-Тестируется факт вызова методов сервисов что меняют состояние этих сервисов. Методы сервисов которые что-то возвращщают (get-методы) лучше не тестировать а мокать.
- В некоторых случаях надо тестировать последовательность вызовов методов для недопущщения определенных багов
Это сильно упрощщало написание юнит-тестов на проэкте. Рекомендую к прочтению
А у нас есть менеджер, который сказал "Хочу 100% покрытие юнит-тестами, и ниипёт".
По-хорошему все методы, вызываемые из тестируемого метода надо мокать.
Мокать - значит мокать. Даже если твой метод ничего не возвращает при вызове из тестируемого метода, он должен быть замокан, по той простой причине, что если ты не замокаешь вызываемый метод, то у тебя может упасть тест метода в котором ты не делал изменений, а это нарушает правило тестирования метода.
О, я не знал, что тут только о дотнетах.
НО, если говорить не только о них, то правила таки актуальны, - как минимум в случае, когда у тебя ынтерпрайз и есть четко регламентированные версии библиотек. У меня сейчас как раз такая история - текущая версия не умеет отличать методы суперклассов и мокать их. Следующая версия умеет - но ее из соображений безопасности нам совсем нельзя. Собака.jpgЕбитесь.
НО, если говорить не только о них, то правила таки актуальны, - как минимум в случае, когда у тебя ынтерпрайз и есть четко регламентированные версии библиотек. У меня сейчас как раз такая история - текущая версия не умеет отличать методы суперклассов и мокать их. Следующая версия умеет - но ее из соображений безопасности нам совсем нельзя. Собака.jpgЕбитесь.
Да Люмен больше и не горит, да
Как человек, который писал довольно сложную хуйню и проверял полностью тестами в отсутсвие реального железа, под которое она предназначена, а потом ошибки были только "не на нашей стороне" не могу согласиться. Юнит тесты от много чего спасают, особенно, от корнер-кейсов.
Моя личная философия тестирования:
1. Юнит тест больше всего необходим на этапе разработки модуля, потому что тесировать модуль, расположенный глубоко в кишках через внешний интерфейс всей системы может быть
а) не удобно, тестировать модуль через внешний интерфейс и сто абстракций - это так же удобно, как азиат, рисующий пятиметровой кистью
б) не все корнер-кейсы через этот внешний интерфейс системы вообще могут возникнуть.
Вот пример из моей области глубокой системщины. Иногда возникает ситуация, когда невозможнотсь выделить нужный объем памяти - это норма, и это нужно обработать. Поэтому да, мы мокаем malloc() и пишем тест.
2. Юнит тест фиксирует контракт модуля
3. Юнит тест тестирует негативные сценарии и корнер-кейсы
4. Модулем (юнитом) может быть разное. Это не обязательно всегда ровно одна функция или один класс, это может быть несколько классов, объединенных в логический модуль, несколько модулей и так далее, главное, чтобы это был законченный модуль с внешним интерфейсом. Ключевая особенность юнит-теста - они не зависят от состояния внешнего мира (от запросов, от баз данных итп).
а) Например, ты можешь протестировать некую структуру данных одим юнит тестом, а в другом юнит-тесте тестировать некую более сложную штуку, которая использует эту структуру данных. Конечно же,тебе не нужно мокать эту структуру, это будет треш.
б) Желательно, чтобы внешний мир в систему приходил через интерфейс, а не использовался где-то в кишах. Я сишник, я могу замокать любой вызов любой функции, мне не нужны интерфейсы, но это всрато
А поверх этого уже интеграционные тесты - вся система целиком в связи с внешним миром (возможно, тестовым). Таких тестов уже не напишешь так много, как юнитов, они более дорогие по написанию и выполнению, ими не пролезешь в каждую щель и не протестируешь разные корнер кейсы. Оин в целом дают понимание, что система работает.
Моя личная философия тестирования:
1. Юнит тест больше всего необходим на этапе разработки модуля, потому что тесировать модуль, расположенный глубоко в кишках через внешний интерфейс всей системы может быть
а) не удобно, тестировать модуль через внешний интерфейс и сто абстракций - это так же удобно, как азиат, рисующий пятиметровой кистью
б) не все корнер-кейсы через этот внешний интерфейс системы вообще могут возникнуть.
Вот пример из моей области глубокой системщины. Иногда возникает ситуация, когда невозможнотсь выделить нужный объем памяти - это норма, и это нужно обработать. Поэтому да, мы мокаем malloc() и пишем тест.
2. Юнит тест фиксирует контракт модуля
3. Юнит тест тестирует негативные сценарии и корнер-кейсы
4. Модулем (юнитом) может быть разное. Это не обязательно всегда ровно одна функция или один класс, это может быть несколько классов, объединенных в логический модуль, несколько модулей и так далее, главное, чтобы это был законченный модуль с внешним интерфейсом. Ключевая особенность юнит-теста - они не зависят от состояния внешнего мира (от запросов, от баз данных итп).
а) Например, ты можешь протестировать некую структуру данных одим юнит тестом, а в другом юнит-тесте тестировать некую более сложную штуку, которая использует эту структуру данных. Конечно же,тебе не нужно мокать эту структуру, это будет треш.
б) Желательно, чтобы внешний мир в систему приходил через интерфейс, а не использовался где-то в кишах. Я сишник, я могу замокать любой вызов любой функции, мне не нужны интерфейсы, но это всрато
А поверх этого уже интеграционные тесты - вся система целиком в связи с внешним миром (возможно, тестовым). Таких тестов уже не напишешь так много, как юнитов, они более дорогие по написанию и выполнению, ими не пролезешь в каждую щель и не протестируешь разные корнер кейсы. Оин в целом дают понимание, что система работает.
клёвое описание, спасибо. Жаль что всякие пхп макаки типа меня юнит тесты только для саморазвития писали. Недавно специально искал более-менее серьёзную контору, с отлаженными процессами, где смогу развиваться, в итоге в первую же неделю выдали доступы от боя и её срм и отправили фиксить баг (да-да, не ловить, а сразу фиксить). Пиздос, но такова отрасль
"Юнит тест фиксирует контракт модуля" - вот это - самый жирный плюс юнит теста. Это означает что создается по факту самопроверяющая база данных о том как должна работать система, а это значит что даже когда с проэкта уйдут все кто его создавал - юнит тесты останутся и при изменениях укажут на баги которые возникнут или скажут что все ок. Ручного регрессионного тестирования на это не напасешься, тестировщики сами не помнят абсолютно всех кейсов, к тому же они могут проверить только с точки зрения пользователя. В итоге без юнит тестов проэкт переходит в состояние "одно фиксим, второе ломаем"
Спасибо, это очень важное дополнение про регрессии при изменениях. Вообще, код, не покрытый тестами и не запускающийся, имеет свойство протухать и приходить в неработоспособное состояние. Мне недавно на тест несколько железок на работе дали, на которых тесты не гоняются. Ну и что думаете? Конечно же на них нашлись баги уровня "нихуя не работает".
Утебя есть черепаха. Ты построил огромный конвеер для помещения черепахи в коробку, а также детектор нахождентя черепахи внутри коробки. Ты помещаешь черепаху в коробку чтобы серез секунду проверить наличие черепахи в коробке. Бессмысленно - черепаха не могла выпрыгнуть из коробки но ты заебался выстраивать весть механизм
Проверка штуки в два раза больше самой штуки
... то есть почти всегда если их вообще писали?
Разве ценность тестов не в возможности легко проверять функционал изменённого кода?
То есть теперь можно менять этот класс как угодно, хранить это Id каким попало образом, шифровать его, отправлять голубями в башню с драконами - и после каждого такого усовершенствования быстро тестить, правильно Id хранится или нет.
То есть теперь можно менять этот класс как угодно, хранить это Id каким попало образом, шифровать его, отправлять голубями в башню с драконами - и после каждого такого усовершенствования быстро тестить, правильно Id хранится или нет.
А её, эту реальность, кто-то оттестировал, чтобы я ей доверял? То-то же... :)
Начальство бесоёбит, требуя увеличить показатели. Показатели увеличивать неоткуда, все что можно ужк сделано, , разве что начать страдать херней, например когда как в армии красят траву зеленой краской. На картинке он написал автоматический тест для программного кода, где, как мне кажется, назначил чему то порядковый номер 42 и тест проверяет что этот вшитый в код номер равен 42. Еще десяток подобных тестов и у него будет нужно количество, которое удовлетворит начальство.
А в чём прикол? Начальство хочет хуйню, программист делает хуйню. Всё по ТЗ. Абсолютно бытовая ситуация. Где смеяться? На что ему стало похуй?
Ты пишешь под ЕС ЭВМ?
И, кстати, ИИ можно использовать как помощника. Если довольно простую функцию надо написать, то какой-нибудь ChatGPT справится с этим на ура ещё и тестов по просьбе напишет сносных. Так, к примеру, за час можно либо самому руками набить функцию, либо сгенерировать шаблон + тесты к нему в ChatGPT)
Только профессиональная литература рекомендует делать наоборот: сначала писать тест, и в нём определить контракт метода, а потом силами IDE сгенерить метод по этому контракту и написать в него нужный код.
Боб Мартин, "Чистый код" и "Чистая архитектура".
С практической точки зрения, в жопу ваш DDD. Если это не игрушечный пример со сложением двух чисел, то это совершенно неудобно. Когда ты пишешь модуль, ты примерноп понимаешь, но сразу безошибочно контракт представить вряд ли получится всегда. Потому что твой модуль может потребовать разные данные/объекты/служебные штуки/итп итд, и контракт в деталях меняется. Если, коненчо, контракт строго не утсановлен заранее.
Мне кажется, что в реальном мире, где в команде над проектом трудиться более 4х разработчиков, мало кто использует чистый TDD. Т.к. кто-то точно не умеет в тдд, кто-то делает это плохо, кто-то делает "так как будто это было тдд". И т.д. в итоге, тот кто умеет в тдд просто скатывается в написание текстов за всеми. А доделывать чью-то работу в режиме нон-стоп вряд-ли кто-то хочет) в итоге все просто пишут код, покрытый тестами в "разумном и достаточном объеме".
В реальном мире мало кто использует любую чистую методологию. Потому что в реальном мире времени на выполнение задач обычно меньше, чем нужно для использования любой методологии. За исключением методологии "хуяк-хуяк и в продакшен", конечно же.
Чтобы написать коммент, необходимо залогиниться
