![[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/}
Дэйв с точностью до минуты помнил момент, когда ему стало](http://img0.reactor.cc/pics/post/full/it-%D1%8E%D0%BC%D0%BE%D1%80-geek-%D0%BA%D0%BE%D0%BC%D0%B8%D0%BA%D1%81-8289008.jpeg "it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,комикс")
Подробнее
[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/} Дэйв с точностью до минуты помнил момент, когда ему стало плевать.
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,комикс
Еще на тему
-Тестируется изменение публично доступного состояния с какой-то внутренней логикой. DTO-шки тестить смысла нет.
-Тестируется факт вызова методов сервисов что меняют состояние этих сервисов. Методы сервисов которые что-то возвращщают (get-методы) лучше не тестировать а мокать.
- В некоторых случаях надо тестировать последовательность вызовов методов для недопущщения определенных багов
Это сильно упрощщало написание юнит-тестов на проэкте. Рекомендую к прочтению
Ни ногой в аутсорс.
За пол года что я здесь постоянные фиксы и игра из нового контента видела только battle pass
если овертаймы не оплачиваются с повышенным рейтом - менеджер идёт нахуй
чтобы было 100% покрытие только нужного кода
НО, если говорить не только о них, то правила таки актуальны, - как минимум в случае, когда у тебя ынтерпрайз и есть четко регламентированные версии библиотек. У меня сейчас как раз такая история - текущая версия не умеет отличать методы суперклассов и мокать их. Следующая версия умеет - но ее из соображений безопасности нам совсем нельзя. Собака.jpgЕбитесь.
НО на первых этапах надо попотеть, да)
П.с. 100% покрытие не оправдываю, но любители "я же точно знаю что без багов сделал", и "стоолько времени эти тесты пишутся, ну их нах" должны гореть
Моя личная философия тестирования:
1. Юнит тест больше всего необходим на этапе разработки модуля, потому что тесировать модуль, расположенный глубоко в кишках через внешний интерфейс всей системы может быть
а) не удобно, тестировать модуль через внешний интерфейс и сто абстракций - это так же удобно, как азиат, рисующий пятиметровой кистью
б) не все корнер-кейсы через этот внешний интерфейс системы вообще могут возникнуть.
Вот пример из моей области глубокой системщины. Иногда возникает ситуация, когда невозможнотсь выделить нужный объем памяти - это норма, и это нужно обработать. Поэтому да, мы мокаем malloc() и пишем тест.
2. Юнит тест фиксирует контракт модуля
3. Юнит тест тестирует негативные сценарии и корнер-кейсы
4. Модулем (юнитом) может быть разное. Это не обязательно всегда ровно одна функция или один класс, это может быть несколько классов, объединенных в логический модуль, несколько модулей и так далее, главное, чтобы это был законченный модуль с внешним интерфейсом. Ключевая особенность юнит-теста - они не зависят от состояния внешнего мира (от запросов, от баз данных итп).
а) Например, ты можешь протестировать некую структуру данных одим юнит тестом, а в другом юнит-тесте тестировать некую более сложную штуку, которая использует эту структуру данных. Конечно же,тебе не нужно мокать эту структуру, это будет треш.
б) Желательно, чтобы внешний мир в систему приходил через интерфейс, а не использовался где-то в кишах. Я сишник, я могу замокать любой вызов любой функции, мне не нужны интерфейсы, но это всрато
А поверх этого уже интеграционные тесты - вся система целиком в связи с внешним миром (возможно, тестовым). Таких тестов уже не напишешь так много, как юнитов, они более дорогие по написанию и выполнению, ими не пролезешь в каждую щель и не протестируешь разные корнер кейсы. Оин в целом дают понимание, что система работает.
Но без интеграционных тестов нет уверенности в работе системы да и рефакторить невозможно.
То есть теперь можно менять этот класс как угодно, хранить это Id каким попало образом, шифровать его, отправлять голубями в башню с драконами - и после каждого такого усовершенствования быстро тестить, правильно Id хранится или нет.
Btw, да, сигнатуры методов ИИ выбирает своевольно, но его можно попросить изменить сигнатуру на нужную постфактум и все равно он сгенерит сносный метод.