Архитектор из дома

[X37WAL!^]

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

т.е. сразу делается fake substitute? иначе тест не пройдет компиляцию

а потом уже добавляю имплементацию, которая удовлетворит моим условиям (green).

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

Немножко не так это работает. Пишем пустой класс. Пишем первый тест, который разумеется fail. Пишем ПРОСТЕЙШУЮ имплементацию нужного метода в классе. Тест проходит. Пишем второй тест, который простейшая имплементация уже не проходит. Меняем имплементацию на чуть более сложную. И так до тех пор, пока удаётся придумать новые тесты (или их параметры), на которых текущая имплементация ломается. Как только это становится сложно придумать - значит имплементация достаточна, можно подчистить код, написать комменты где нужно и двигать дальше.
Если у нашего класса есть collaborators, то мы их мокаем при помощи готового фреймворка, врукопашную разумеется не пишем...

[Интеррапт]

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

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

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

с опытом / набиванием руки многие ошибки уже не делаются, отлавливать не особенно чего надо (don't take it personally)

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

[Сабина]

Так ты еще и аджайл исповедуешь?

Так грустно сказал как будто все идеалы рухнули . Это в тебе просто категоричность молодости говорит. Чтобы понять до конца аджайл нужно достаточно поработать в индустрии, причем здесь, но с другой стороны быть очень open minded and open to new things .

[Сабина]

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

т.е. сразу делается fake substitute? иначе тест не пройдет компиляцию

а потом уже добавляю имплементацию, которая удовлетворит моим условиям (green).

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

Немножко не так это работает. Пишем пустой класс. Пишем первый тест, который разумеется fail. Пишем ПРОСТЕЙШУЮ имплементацию нужного метода в классе. Тест проходит. Пишем второй тест, который простейшая имплементация уже не проходит. Меняем имплементацию на чуть более сложную. И так до тех пор, пока удаётся придумать новые тесты (или их параметры), на которых текущая имплементация ломается. Как только это становится сложно придумать - значит имплементация достаточна, можно подчистить код, написать комменты где нужно и двигать дальше.
Если у нашего класса есть collaborators, то мы их мокаем при помощи готового фреймворка, врукопашную разумеется не пишем...

Всегда приятно когда люди до единого слова понимают о чем речь

[Сабина]

Я вот только не могу понять, как с обсуждения позиции архитекта перешли плавно на кодировсчиков?

Ну никто не мешает вам высказаться по изначальной теме и вернуть дискуссию в правильное русло.

Изначальная тема расчитана на западное побережье. Я о реалиях западного побережья предпочитаю слушать, а не писать.
Но все равно непонятно, при чем тут кодитровщики.

Ну свернула тема в оффтопик, все-равно по делу уже мало было высказываний, вам жалко что-ли?

В том-то и дело, что картина для архитекторов на разных побережьях - разная.
Могу что-то внятное сказать о восточном поберезье, если интересно:
на свободный график с работой из дому можно попасть 2-мя путями:
1, Старые контакты, хорошо знают, берут, потому что знают, что будет результат.
2. Новый контракт, сначала сильно нарабатывается авторитет, есть уже успешные проектики или ступеньки в проекте, или "подвиги" в маинтенанце чего-то уже существующего,
тогда можно уже руки выкручивать нащет расписания, работы из дому, ухода с полдня по необходимости и тд. Но результат давать надо все равно постоянно.

Ето - насчет атрибута "работа из дому".
Насчет скиллс и круга обязанностей архитектора - и так вроде понятно. Но все равно все сворачивается на код. В лучшем случае в обсуждение включайтся методики рзработки и QA

С чем то трудно не согласится но не совсем поняла про контракты . Речь только о фултайм если что

[Alexandr]

А где во всей этой лабуде затесались "паттерны" про которые все любят спрашивать, но редко кто применяет ?

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

Синглтон, как уже давно доказано - это анти-паттерн, ибо не тестируется. А вот а-фэктори - это таки да, наше всё

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

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

в общем-то согласен

[Ljolja]

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

ты не допонял, ето новая функция и в релиз она не идет, тест не может накрыться, поскольку того для чего он был предназначен, нет. А драгоценное время ушло. Если бы ты начал с функции, ранше бы понял, что идея 1. doesn't fit

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

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

[Мальчик-Одуванчик]

ну под устоялась можно разное понимать. В моем понимании устоялась - это, когда интерфейс класса понятен и принят, а не, когда уже кучу всего написано.

Ну нет, так дело не поймет, посколько я так понимаю, что вы с TDD дело не имели, правильно? Иначе бы не приводили в качестве аргумента "это, когда интерфейс класса понятен и принят", т.к. это ну никак не противоречит TDD. Наоборот это самая первая стадия - когда к интерфейсу пишутся tests stubs для последующей имплементации процесса red/green/refactor.

Интерфейс - штука параметризуемая, а юнит-тесты больше относятся к специализации.

[АццкоМото]

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

Я вот привык спать в спальне, а обедать - в столовой. И, соответственно, чтобы требования писал инженер по требованиям, а не юзер и не архитектор.

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

А для этого на ревью требований приглашается лид по тестированию или тот, кому он делегирует

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

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

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

You are missing my point. О нуле я задумался и без всяких тестов, не дебил чай и не джуниор. И код для его особой обработки написал. Я просто неправильно понимал его значение, следовательно, у меня и тест бы был точно такой же неправильный
Единственное, чего помогают избежать юнит-тесты, это случайную поломку давно написанного и работающего кода. Но если в команде работают достаточно профессиональные люди, такое случается настолько редко, что юнит-тесты - слишком высокая цена

[АццкоМото]

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

Чтобы два раза не вставать. IoC не полностью бесполезная штука, но использование его только для того, чтобы что-то стало "тестируемым" - злейшее зло. Любое усложнение кода ради тестов - злейшее зло и глупость несусветная.

[Мальчик-Одуванчик]

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

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

[X37WAL!^]

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

Чтобы два раза не вставать. IoC не полностью бесполезная штука, но использование его только для того, чтобы что-то стало "тестируемым" - злейшее зло. Любое усложнение кода ради тестов - злейшее зло и глупость несусветная.

Ээээ, а где у нас усложнение _кода_?

Без IoC имеем

Code: Select all

public MyClass()
{}

public void DoSomething()
{
Service1.Instance.DoFoo();
Service2.Instance.DoBar();
}

c IoC имеем

Code: Select all

private IService1 service1;
private IService2 service2;

public MyClass(IService1 s1, IService2 s2)
{
this.service1=s1;
this.service2=s2;
}

public void DoSomething()
{
this.service1.DoFoo();
this.service2.DoBar();
}

Кроме двух параметров в конструкторе и двух полей чегой-то у нас усложнилось внутри собственно кода? А приобрели мы много. Как минимум мгновенное понимание любым другим девелопером (при взгляде на конструктор), что без двух явно переданных dependencies этот класс работать не будет. Это если недостаточно бенефитов от лёгкого тестирования.
Это _хорошо_ ещё когда наши смуглые друзья пишут ServiceBlabla.Instance. А то ведь часто Repository.Instance.КакойТоКлассЛеньДуматьГдеЕмуБыть

[АццкоМото]

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

Чтобы два раза не вставать. IoC не полностью бесполезная штука, но использование его только для того, чтобы что-то стало "тестируемым" - злейшее зло. Любое усложнение кода ради тестов - злейшее зло и глупость несусветная.

Ээээ, а где у нас усложнение _кода_?

Без IoC имеем

Code: Select all

public MyClass()
{}

public void DoSomething()
{
Service1.Instance.DoFoo();
Service2.Instance.DoBar();
}

c IoC имеем

Code: Select all

private IService1 service1;
private IService2 service2;

public MyClass(IService1 s1, IService2 s2)
{
this.service1=s1;
this.service2=s2;
}

public void DoSomething()
{
this.service1.DoFoo();
this.service2.DoBar();
}

Кроме двух параметров в конструкторе и двух полей чегой-то у нас усложнилось внутри собственно кода? А приобрели мы много. Как минимум мгновенное понимание любым другим девелопером (при взгляде на конструктор), что без двух явно переданных dependencies этот класс работать не будет. Это если недостаточно бенефитов от лёгкого тестирования.
Это _хорошо_ ещё когда наши смуглые друзья пишут ServiceBlabla.Instance. А то ведь часто Repository.Instance.КакойТоКлассЛеньДуматьГдеЕмуБыть

Вы и в правду не видите усложнения кода? Даже при том, что эти два куска кода различаются визуально по размеру в 2 раза? При этом в реальной жизни вместо

Code: Select all

Service1.instance.doFoo()

может быть просто

Code: Select all

doFoo()

А вот вместо

Code: Select all

this.service1.DoFoo();

уже

Code: Select all

if (this.service1 != null) {
   this.service1.DoFoo();}
else {
   throw new MyFreakingNewExceptionResidingInASeparateFileThatNobodyNeeds ("You, moron, next time do not pass nulls, Ok?");
}

--- И так дважды в совершенно тривиальном примере

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

[АццкоМото]

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

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

Категоричность - это ложь во имя простоты. Разумеется, есть ситуации, когда юниттесты оправданны. Если завтра я буду писать yet another STL/Boost/Java Collections - юниттестов у меня может быть больше, чем осмысленного кода. Но как-то мне уже годиков под сраку, а я ни разу еще этого не делал. И 146% Привета - тоже. А в повседневной жизни мы пишем что-то типа:

Code: Select all

public List<Shit> sortMyShit() {
   return myShit.sort();
}

Вот очень умнО тестировать такой метод.

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

[Мальчик-Одуванчик]

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

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

Категоричность - это ложь во имя простоты. Разумеется, есть ситуации, когда юниттесты оправданны. Если завтра я буду писать yet another STL/Boost/Java Collections - юниттестов у меня может быть больше, чем осмысленного кода. Но как-то мне уже годиков под сраку, а я ни разу еще этого не делал. И 146% Привета - тоже. А в повседневной жизни мы пишем что-то типа:

Code: Select all

public List<Shit> sortMyShit() {
   return myShit.sort();
}

Вот очень умнО тестировать такой метод.

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

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

[АццкоМото]

Для тестирования базовой функциональности для случая a) не столь важно что вернет сокет сколь более важно исключить саму сетку и связанные с ней настройки, таймауты, результаты запросов из базового тестирования.

Ага, конечно. Сервера в 146% случаев возвращают то, что не прописано никакими спецификациями и что разработчик не мог представить в самом страшном сне - а из этого есть отличное следствие: и в тестах это учтено не будет никогда
А вот кстати влияние сетки оттестировать в автоматическом режиме насколько хватает паранойи - отлично. Единственное, я бы не использовал юниттесты, а скорее fake server, но в каких-то нюансах и юниттесты бы сгодились

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

И сюрпризов не было, да? Ну, я тогда Станиславский. Т.е. - не верю

[Мальчик-Одуванчик]

Для тестирования базовой функциональности для случая a) не столь важно что вернет сокет сколь более важно исключить саму сетку и связанные с ней настройки, таймауты, результаты запросов из базового тестирования.

Ага, конечно. Сервера в 146% случаев возвращают то, что не прописано никакими спецификациями и что разработчик не мог представить в самом страшном сне - а из этого есть отличное следствие: и в тестах это учтено не будет никогда
А вот кстати влияние сетки оттестировать в автоматическом режиме насколько хватает паранойи - отлично. Единственное, я бы не использовал юниттесты, а скорее fake server, но в каких-то нюансах и юниттесты бы сгодились

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

И сюрпризов не было, да? Ну, я тогда Станиславский. Т.е. - не верю

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

[X37WAL!^]

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

Мне пока очевидно только одно - что вы (похоже) привыкли писать код в виде классов, дизайн которых SOLID principle нарушает налево и направо. Оно конечно может нормально работать в результате, но тестировать, модифицировать и поддерживать такой код впоследствии - мало радости...

[АццкоМото]

Мне пока очевидно только одно - что вы (похоже) привыкли писать код в виде классов, дизайн которых SOLID principle нарушает налево и направо.

А SOLID - это что-то божественное и непреложное? Собственно, единственное, что я нарушаю из этого принципа направо и налево - букву D ибо считаю ее злым злом, если возводить этот принцип в абсолют. Но я предлагаю сконцентрироваться на сути дискуссии. Вот краткая ретроспектива:

я: нельзя усложнять код ради тестирования
вы: да разве же это усложнение?
я: ну да, очевидно, усложнение
вы: а ты, чудило, вообще говнокод пишешь

в таком раскладе, я, очевидно, спор проиграл еще до того, как в него ввязался

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

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

[АццкоМото]

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

Собственно, на этом можно и закончить. Если сервер и клиент были написаны одним человеком и "взлетели", то сгодится любая методология. Даже самая дремучая. Я вот тоже редко с собой спорю

[reality]

Ага, конечно. Сервера в 146% случаев возвращают то, что не прописано никакими спецификациями и что разработчик не мог представить в самом страшном сне - а из этого есть отличное следствие: и в тестах это учтено не будет никогда
А вот кстати влияние сетки оттестировать в автоматическом режиме насколько хватает паранойи - отлично. Единственное, я бы не использовал юниттесты, а скорее fake server, но в каких-то нюансах и юниттесты бы сгодились

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

[X37WAL!^]

Мне пока очевидно только одно - что вы (похоже) привыкли писать код в виде классов, дизайн которых SOLID principle нарушает налево и направо.

А SOLID - это что-то божественное и непреложное? Собственно, единственное, что я нарушаю из этого принципа направо и налево - букву D ибо считаю ее злым злом, если возводить этот принцип в абсолют. Но я предлагаю сконцентрироваться на сути дискуссии. Вот краткая ретроспектива:

я: нельзя усложнять код ради тестирования
вы: да разве же это усложнение?
я: ну да, очевидно, усложнение
вы: а ты, чудило, вообще говнокод пишешь

в таком раскладе, я, очевидно, спор проиграл еще до того, как в него ввязался

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

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

во-первых, не надо так нервно, я как раз стараюсь какие-то аргументы привести, а вы долбите практически без аргументов: зло, плохо, усложняем код. "Очевидно"
во-вторых, нифига не очевидно. Код, который ВЫГЛЯДИТ проще, совсем необязательно проще для понимания, отладки и изменения.

[X37WAL!^]

Ага, конечно. Сервера в 146% случаев возвращают то, что не прописано никакими спецификациями и что разработчик не мог представить в самом страшном сне - а из этого есть отличное следствие: и в тестах это учтено не будет никогда
А вот кстати влияние сетки оттестировать в автоматическом режиме насколько хватает паранойи - отлично. Единственное, я бы не использовал юниттесты, а скорее fake server, но в каких-то нюансах и юниттесты бы сгодились

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

+1. Или вместо чуши получим какой-нибудь timeout exception...

[АццкоМото]

Ага, конечно. Сервера в 146% случаев возвращают то, что не прописано никакими спецификациями и что разработчик не мог представить в самом страшном сне - а из этого есть отличное следствие: и в тестах это учтено не будет никогда
А вот кстати влияние сетки оттестировать в автоматическом режиме насколько хватает паранойи - отлично. Единственное, я бы не использовал юниттесты, а скорее fake server, но в каких-то нюансах и юниттесты бы сгодились

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

Можно, а в ряде случаев - даже нужно. Вопрос в том, что заставляет думать, что такой тест должен быть юниттестом. Хуже того, что заставляет нас написать такой тест ДО основного кода, как диктует ТДД
В 99% случаев поможет fake server, а вовсе не извращения типа DI/IoC

[АццкоМото]

во-первых, не надо так нервно, я как раз стараюсь какие-то аргументы привести, а вы долбите практически без аргументов: зло, плохо, усложняем код. "Очевидно"

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

во-вторых, нифига не очевидно. Код, который ВЫГЛЯДИТ проще, совсем необязательно проще для понимания, отладки и изменения.

код, в который добавляются лишние параметры, нужные только для тестирования, ВСЕГДА сложнее, статистически содержит больше ошибок, труднее для понимания и отладки. это медицинский факт, спорить тут по большому счету не о чем. если мне Самый Главный и Великий Програмизд Мира будет рассказывать, что для любого внешнего по отношению к данному классу, что мы пишем и хотим тестировать, воздействия извне мы можем написать энторфейс, потом заставить это внешнее имплементировать этот энторфейс и его же имплементировать в тестах, а в параметрах нашего тестируемого класса принимать абстрактную реализацию этого энторфейса и при этом не ухудшить сложность, понимаемость этого кода, не внести новых багов - я буду смеяться ему в лицо. Это лажа. Так же смешно, как утверждение, что мы можем сконструировать автомобиль, в котором можно заменить что угодно - руль, дрыгатель, коробку, колесо, пепельницу - на что-то совершенно другое так, чтобы оно могло и дальше ездить и при этом не стало сложнее. Муахххаххха