Юнит тесты для "системного" приложения
1) для того, чтобы код был тестируемым.
Вот именно с этим у меня и наблюдаются проблемы.
Я не хочу исключительно только для тестирования добавлять море вещей которые мне совсем не нужны.
2) чтобы класс отвечал только за то, чем он занимается.
А класс и не занимается сжатием, за это отвечает другой класс.
Если кто-то захочет изменить сжатие, то он будет это менять в другом месте.
3) расширяемость
Зачем предусматривать расширяемость, когда эта расширяемость не понадобится.
Ну зачем мне автомобилю делать складываемые крылья или цеплять замаскированный парашют, на тот случай если он вдруг упадет в ущелье?
Event-ы наше всё!
И чем они мне помогут? Ну выдам эвент с ошибкой, а ключа то у меня нет к какой конкретно записи относится ошибка. Уникальный ключ как-то делать?
Записывать все данные может быть и можно. Но для этого у меня и так внешний Action есть.
Я не хочу исключительно только для тестирования добавлять море вещей которые мне совсем не нужны.
Ну нет проблем :) Просто в таком случае ты пишешь код, который нельзя протестировать юнит-тестами. Есть и другие способы протестировать код :)
А класс и не занимается сжатием, за это отвечает другой класс.
Если кто-то захочет изменить сжатие, то он будет это менять в другом месте.
Твой класс как минимум создает объект, который занимается сжатием и конфигурирует/инициализирует этот объект.
Зачем предусматривать расширяемость, когда эта расширяемость не понадобится.
Затем, что это приятный бонус, который ты получаешь совершенно бесплатно, если проектируешь софт по определенным правилам :)
Ну зачем мне автомобилю делать складываемые крылья или цеплять замаскированный парашют, на тот случай если он вдруг упадет в ущелье?
В автомоболе можно поставить вместо приборной дочки полноценный дисплей и тогда помимо изображения любой технической информации о состоянии машины, можно еще показывать навигационную систему или даже киношки. При этом телевизор получается без каких-либо дополнительных затрат.
Твой класс как минимум создает объект
Ну и что, кто то всё равно должен его создать. Всё что мы теряем - это динамическая замена. Которая относится к разряду ненужных.
если проектируешь софт по определенным правилам
правила и так есть, только не следует понимать их буквально.
То бишь, нужно мне в классе, допустим, 10 операций, то всех их абсолютно обуть в классы и интерфейсы и инициализировать строго снаружи.
В автомобиле можно поставить вместо приборной доски полноценный дисплей
Можно, но вот парашют и крылья считаешь, что не нужно?
Вот у меня такое же деление и есть, когда нужно - то делаем, когда не нужно - то нет.
А вот лет 50 так назад, ты бы тоже считал, что можно поставить туды "полноценный дисплей"?
С другой стороны, у меня в ентом авто приборная доска и управление работает чисто механически. И что бы переделать всё в цифру нужно затратить много времени и денег.
То бишь, дырки для крепления сделать еще могу, а вот подсоединить текущие приборы через разъем ну никак не получится.
Вообще то, как оказалось, есть более приемлемый метод для меня.
достаточно вместо
compressor.Compress(fileName);
написать
CompressFile(fileName);
virtual void CompressFile(string fileName)
{
compressor.Compress(fileName);
}
А затем уже замокать эту виртуальную функцию.
Ну вот если устройство мне посылает дату 30.02.2021 - это как класифицировать?
Сорры. Только сейчас заметил
Это особенность устройства. Программист писал насчет фичи, но общий принцип такой - устройство может посылать инфу в определенном кодирунге, на китайском языке, в странном формате. Если такой вывод использовать нельзя, то и устройство использовать нельзя. Если можно с последующей обработкой. то нужен код обработки. Но долбить эту особенность устройства юниттестами (долбить - потому что юниттесты запускаются автоматически регуларно, проверяя код) нет смысла - особенность устройства извeстна и не изменится. А вот собственный код обработки особенности можно и нужно
особенность устройства известна и не изменится
-----
Хи-хи...
Из того что помню.
Три завода, три инсталяции Оракла.
Каждая инсталяция - мало того что другой версии, так еще и со своей локалью.
Соответственно - формат даты и времени - разный, порядок сравнения и сортировок - тоже разный.
Код - общий для всех баз...
нет смысла
-----
Оно, вообще-то, программируемое. 
Хи-хи... Из того что помню.Три завода, три инсталяции Оракла.Каждая инсталяция - мало того что другой версии, так еще и со своей локалью.Соответственно - формат даты и времени - разный, порядок сравнения и сортировок - тоже разный.Код - общий для всех баз..
Ты реально не понимаешь, что нет нужды тестировать порядок сравнения и сортировку в Оракле? Или просто прикидываешься?
Если такой вывод использовать нельзя, то и устройство использовать нельзя.
вывод использовать нельзя, но вот устройство нужно.
Это как раз и тестирует "мой" код - он не должен обваливаться если даже устройство пошлет что то неправильное.
Так что тесты нужны, хоть часть будет юнит тестами, а часть интеграцион тестами.
особенность устройства извeстна и не изменится
никакой документированной особенности устройства доверять нельзя 
Всё нужно проверять. Пару раз железячников на этом и поймали.
Каждая инсталяция - мало того что другой версии, так еще и со своей локалью.
Как часто у одной инсталляции менялись свойства?
Оно, вообще-то, программируемое.
Ты хотел сказать конфигурируемое. Програмируемое - это дата 31.02.2021. Напрограмировали
Проблема конфигурируемых внешних систем в том, что свою реализацию пишут под конкретную конфигурацию(как правило собственная реализация тоже конфигурируема). Проверить все это невозможно даже в принципе. Система сконфигурирована под джейсон, а пришел хмл. Система написана под определенный Трансферобьект, а пришел совсем другой обьект или вообще стринг.
Поэтому пока система бегает, считают, что внешняя часть тоже неизменяема. Можно ораклувскую инстанцию вообще на другой сервер перекинуть и какой смысл что то там тестировать. Понятно, что приложение без базы данных не стартанет и если настройки изменить, то может эту самую базу вообще не найти.
Потом если у инсталляции установили китайскую локаль, то значит так надо было. Не думаю, что имеет смысл в приложении опрашивать текущую локаль базы данных. Я даже не заню, кто то это делает? Просто настраивают систему (прога+база) и это эта связка до следующей настройки считается неизменяемоj
вывод использовать нельзя, но вот устройство нужно.
------
Ну так понятно что деваисе надо мокать... вот чего аппоненты не желают понять - надо знать какие сюрпризы может дать деваисе и в доках оно не описано - надо дрючить девайсе из тестов пока не убедишься что собрал всю коллекцию проблеm...
Как часто у одной инсталляции менялись свойства?
------
А какая разница?
Я не контролирую сервера - может поменяться в любой момент и без уведомления.
То, что это не декаки с момента установки ситуацию никак не меняет.
Проверить все это невозможно даже в принципе.
-----
Ну наконец-то... правда пока не вижу понимания того что проверить можно только то об чем знаешь...
значит так надо было.
------
Да ну?
Мне вот всегда казалось, что это от непонимания того, что от этого что-то зависит.
По крайней мере в рамках одного предприятия.
Не думаю, что имеет смысл в приложении опрашивать текущую локаль базы данных.
------
Т.е. принимается как норма, что как только в запросе требуется фильтрация по дате, то приложение дожно упасть? Ну или выдать какую-нибудь чушь...
Не думаю, что имеет смысл в приложении опрашивать текущую локаль базы данных.
------
Еще раз.
Автоматизированное рабочее место.
Одна инсталяция программы.
Работает с тремя различными серверами, каждый из которых имеет свой диалект СКЛ и другую локаль.
Я чего - должен бегать туда каждый раз как девочке приспичит что-то сделать на другом серваке?
девайс не надо, только приложение
------
Присылали мне как-то файлик для импорта.
Без документации на формат - только ссылка на то, что он в каком-то внутреннем стандарте третьей стороны - они ничего другого экспортировать не умели. Готового редера - не было.
Внутри только дат было три разных формата, причем один из них вводился текстом в ручную...
Так будем тестить приложение или будем дрючить источник?
ЕМНИП Datetime - это просто число и локаль там по большому счету не нужна. А для того, чтобы безошибочно конвертнуть строку в DateTime можно использовать функцию CONVERT и передавать в ней дату в любом удобном и при этом заранее изместном виде :)
Подозреваю, что 
Murr как обычно простелил себе колено :)
это просто число
------
Вообще-то, в контексте СКЛ это будет строка в определенном формате.
можно использовать функцию CONVERT
------
Можно.
Но можно упереться в ограничение на длинну выражения в IN...
И, кстати, КОНВЕРТ тормозит довольно прилично... хотя основное - он там вообще не нужен, если не требуется вывод в определенном формате...
Murr как обычно простелил себе колено
-----
Ну если понимае маленького момента что локаль базы и локаль сессии - это две независимых локали есть выстрел в колено - то - да, прострелил оба... 
Как насчет изучения мат.части? 
Без документации на формат...или будем дрючить источник?
В этом случае нужно как то добыть информацию, да и задача несколько другая.
В моём случае задача - приложение не должно вылетать при любых ошибках в источнике.
Поэтому что и как выдает источник меня не волнует. Меня волнует, как я буду принимать данные с ошибками.