Юнит тесты для "системного" приложения
-----
Да ну? И как же ты будешь эмулировать результат переполнения буфера если об этом даже не в курсе?
это надо смотреть в доках.
-----
Ну так смотри.
А то получается ни доkи не посмотрел, ни практики не поимел, но об том КАК - вполне готов говорить... причем начиная с того что тебе непонятны описанные проблемы... 
достаточно для того чтобы извещение о добавлении нового каталога не приходило.
-----
Не-а... это мониторинг субфолдеров. Т.е. если есть вложенные папки - будет-не-будет трекировать в них тоже...
Удобно - задал "С:\\" с подкаталогами и весь диск мониторишь...
В том то и дело что не знаю, догадываться могу, но не знаю, как он будете себя вести во всех ситуациях. На сетевом диске например.
Ты не можешь выяснять это юниттестами.
А отчего все должны запускаться при каждом коммите? Даже и на работе у нас было разделение, на ежедневные и после коммитные.
Ладно, при катгдом бильде. НО это неважно, политика фирмы, ты же должен расчитывать на то, что тесты будут долбиться постоянно много раз и в разных условиях, причем часто там, где конкретное исследование твоего мониторa нафиг не впало. Еще раз - коллега скачает код, код рухнет на бильде и именно коллега будет трахаться, не понимая, как его изменения могли привести к такому повреждению кода, что перестали идти юниттесты.
Ничего он думать не будет, у него будет сообщение с описанием проблемы. Типа "не могу создать тестовый каталог".
Ты
походу никому не запарывал юниттесты
Результат - злоба за потерянное время.
Маловероятно для
Значит возможно. Значит нельзя.
После окончания теста каталог будет снесен вместе с содержимым? Безусловно и свободное место будет проверяться.
Представь, что у коллеги есть такой же каталог и там дорогие его сердцу фотографии шефа. Он запускает тесты, все прошло на ура и через пару дней он узнает, что ТВОЙ код что то удалил на ЕГО компе. Без запросов.
Зачем мне инвестировать время в приложение которое идет на помойку.
Точно затем же, зачем мы все это здесь обсуждаем. Какова цель создание приложения, которое идет на помойку? Научится делать правильно с учетом возможных последствий. Представь себе, что ты сдал униттест как учебное приложение во время собеседования. А там косяк...
Да ну? И как же ты будешь эмулировать результат переполнения буфера если об этом даже не в курсе?
Мок не должен работать как оригинал. Более того, мок вообще не должен работать. Он должен уметь симулировать ответы оригинала. Нельзя протестовать юниттестами то, о чем не имеешь представления. Можно проверить свой код на устойчивость к общим ошибкам, но не к ошибке, о существовании которой ты не подозреваешь и которая возникает только в определенных условиях. Нельзя надеятся юниттестами что то отловить, о чем не подозреваешь - они предназначены для СТРОГО определенных целей и определенных программистом.
А то получается ни доки не посмотрел, ни практики не поимел, но об том КАК - вполне готов говорить... причем начиная с того что тебе непонятны описанные проблемы...
Проблему Программист понял правильно - недостаточная абстракция при тестировании юниттестами, попытка применить юниттест для изучения работы системы целиком. Тесты для системной функции нафиг никому не нужны.Более того - они сами источник ошибок и потери времени.
Ну так это я нашел только после реального теста с файловой системой.
Ну если ты чтение мануалов хочешь заменить тестами, то у тебя долгий и трудный путь :)
FileSystemWatcher.NotifyFilter:
The default is the bitwise OR combination of LastWrite, FileName, and DirectoryName.
Это всё к тому что не нужно тестировать системные функции - они и так правильно работают.
Во-первых, тебе это говорили с самого начала.
Во-вторых, это правило распространяется не только на системные функции, но и вообще на все third party объекты. При этом это не просто объекты от посторонних производителей. При создании юнит-теста все внешние связи принимаются как работающие без ошибок. Даже если это "соседний" класс и тойже самой сборки, что и твой unit under test.
Как бы я с виртуальными тестами не извращался никогда бы не нашел.
Это да. Потому что искать надо было в мануалах. Тесты существуют не для поиска документации.
Да ну? И как же ты будешь эмулировать результат переполнения буфера если об этом даже не в курсе?
Не понимаю, в чем проблема?
Ну так смотри.А то получается ни доkи не посмотрел, ни практики не поимел, но об том КАК - вполне готов говорить... причем начиная с того что тебе непонятны описанные проблемы...
AlexNek спрашивал как написать тест. При этом он не в состоянии ни описать проблему и ни сформулировать, что же он хочет протестировать. В таких условиях приходится фантазировать. А в результате выясняется, что он просто не прочитал мануал.
Не-а... это мониторинг субфолдеров
Понимание данного аспекта приходит позже 
А поначалу кажется что всё по другому - "Gets or sets a value indicating whether subdirectories within the specified path should be monitored."
Если каталоги не мониторятся, то так вроде и нужно.
Ты не можешь выяснять это юниттестами.
Ну а чем тогда?
Меня сопровождение и прочее как-то совершенно не интересует в данное время.
Мне нужна какая то помощь во время разработки.
Да и на будущее делать эмулятор файловой системы совсем не хочется.
что у коллеги есть такой же каталог
Имя достаточно специфическое, да и можно документацию написать.
Это будет проще чем городить эмулятор файловой системы. Тем более что простых врапперов будет недостаточно.
Вот как раз сейчас новая проблема. Все по частям работает замечательно - а совместно фигвам. Чего то опять не учёл.
Научится делать правильно с учетом возможных последствий.
Ну если по теории нужно делать эмулятор и это будет правильно, то я не вижу когда данный путь будет приемлен. Затраты и результат просто несопоставимы.
Ну если ты чтение мануалов хочешь заменить тестами
Это всё хорошо читать когда нашел проблему и ее решение.
При создании юнит-теста все внешние связи принимаются как работающие без ошибок.
тогда получается что если мы принимаем данные от какого-то устройства, то они должны приходить без ошибок?
Да и на будущее делать эмулятор файловой системы совсем не хочется.
Mock-Object - это не эмулятор файловой системы :)
Это всё хорошо читать когда нашел проблему и ее решение.
Слушай, ну ведь дело-то не в этом. Дело в том, что ты не можешь сформулировать запрос.
В конце-концов, даже если бы не было проперти NotifyFilter, код DirectoryWatcher'а все равно можно сделать рабочим. Главное идентифицировать проблему. Ты этого не сделал. И тесты тут не при чем.
тогда получается что если мы принимаем данные от какого-то устройства, то они должны приходить без ошибок?
Нет. Есть разница межу "данные не имеют ошибок" и "компонента работает без ошибок".
Собственно говоря, даже если компонента содердит какие-то ошибки, ты все равно должен исходить из того, что компонента работает правильно.
Т.е. баг - это фича, с которой тебе надо жить и найти пути обхода. Т.к. внешнюю компоненту ты все равно не сможешь изменить.
Меня сопровождение и прочее как-то совершенно не интересует в данное время.Мне нужна какая то помощь во время разработки.
AlexNek, ты определись, что тебе нужно. Если тебе нужно сделать законченное(пусть и учебное) классическое приложение с законченным циклом разработки, то нужно делать правильно. Если тебе нужно решить конкретную проблему(быстро выяснить, как что то работает), то неважно, какие средства ты у себя локально используешь. Они просто не должны попадать в общий репозиторий. Разумеется юниттесты удобны для запуска куска кода.
Имя достаточно специфическое, да и можно документацию написать.Это будет проще чем городить эмулятор файловой системы.
Нет. Сорри, нагадить в лифте проще, чем до туалета добежать. Но есть вещи, которые делать ну нежелательно. Чел никакую документацию читать не будет, просто потому что ему твой модуль нафихг не впал. На крупной фирме с сотней программистов и кучей отделов никому не интересно, что ты там наваял и что нужно на своем компе организовать, что бы все стартануло.Если чел с опытом, он увидит, что чужие тесты не идут и скачает с репозитория версию без своих изменений. Втиснет ее в среду разработки. Стартанет тесты. Увидит, что тесты не идут. И потребует привести тесты в порядок, что бы они запускались на любом компе, ибо без этого нельзя. Или в настройках проги будет сетевой каталог, которого просто с билдсервера не видно и когда ВСЯ фирма не сможет больше мержить, потому что внезапно перестали идти тесты и шеф будет искать виноватого в паре-сотне часов простоя - тогда будет весело.
Затраты и результат просто несопоставимы.
Просто нужно отказываться от идеии быстро-быстро сделать все на коленке. В принципе я могу представить себе ситуацию, когда расходы на юниттесты делают весь модуль нерентабельным - слишком сложно тестировать. Но в твоем случае (я не программирую на шарпе) на яве это элементарно.Проблема просто понять, где и для чего нужны юниттестy
тогда получается что если мы принимаем данные от какого-то устройства, то они должны приходить без ошибок?
Ошибка - это неожиданная и не предусмотренная реакция кода на ситуацию. В шарпе ексцепшионы есть? так вот выброс исключения "переполнение буфера" - это не ошибка. Это ожидаемая реакция на черезвычайную ситуацию.Ошибка - это типа когда ты читаешь имя файла и если там есть пробел, то вдруг вылетает нульпойнтерексцепшион. И это никто не ожидает и так быть не должно.
Странный ты.
Ты понимаешь, что в данном случае проблема не в мануале?
Проблема в том, что AlexNek захотел использовать некий инструмент и при этом не понял, для чего этот инструмент нужен и как им пользоваться.
Ну это как если бы тебе дали зажигалку и сказали, "этой штукой разжигают огонь и можно круто пожарить шашлыки". А ты такой взял эту зажигалку, сел в машину и спалил ее к чертям, т.к. там тоже есть "зажигание" и вообще машина с ДВС едет за счет горения.