Юнит тесты для "системного" приложения
Я говорил о реальном тесте, который мне нужен.
Мы. Потому что юниттест работает только и исключительно только внутри програмного кода. Если я неправ, то приведи пример обратного. Поэтому мы передаем в тест тестируемый обьект, вызываем тестируемую функцию и проверяем ресультаты. Тестируемая функция внутри кода работает исключительно с другими элементами кода, никогда не с файлами.
Так что можно долго и нудно моделировать и усё будет в порядке.
Именно. FileSystemWatcher управляет мониторингом файлов. Ты не можешь юниттестами проверять поведение этого класса, потому что ты ЗНАЕШь как он себя поведет. Зачем здесь юниттесты, которые будут запускаться автоматически при каждом коммите в репозиторий и при каждом построении приложения? FileSystemWatcher как работал максимум с 80 файлами так и будет это делать. Какая цель проверять
это на каждом компе, куда попадет програмный код? Заметь, не приложение будет запущено, а именно попадет програмный код. Билдсервер, компы коллеg
Так в тестах он и будет создаваться, всё с нуля, на "чистой системе".
А права у него есть "создавать"? А если в системе есть уже такой каталог? После окончания теста каталог будет снесен вместе с содержимым?
Приложение то показать и выбросить.
Вот именно. Это учебное приложение. Опустим, что тебя конкретно никто не тестирует. Но имхо, если делаешь учебное приложение, ты должен делать так, как надо. Потому что имхо запустить юниттесты для меня на внешний ресурс это концептуальная ошибка.Опасно. Может упасть в любой момент и твой коллега будет сидеть и думать, что он сломал в системе и почему у него üниттесты не идут.
А причем тогда файловая система?
System.IO.File.GetAttributes(path);
Ты привел кусок кода, написал:
Ну вот кусок кода для настройки. Вроде всё верно. А гад реагирует на копирование каталога.
я из твоих слов делаю вывод, что приведенный тобой код работает неправильно. К сожалению, ты в лучших традициях 
Murr'а не указал, что именно там не работает. Поэтому мне пришлось фантазировать. И я предположил, что когда ты начинаешь мониторить каталог:
//Start monitoring.
_watcher.EnableRaisingEvents = true;
а судя по твоему коду, мониторить ты начинаешь установив значение проперти EnableRaisingEvents в true, ты не различаешь файл и директорию. Очевидно, что если в _watcher был передан путь к директории, то должна быть сгенерирована ошибка. Именно это и проверяют тесты, которые я привел в качестве примера.
А зачем их моделировать?
Затем, что ты почему-то решил писать юнит-тесты.
Сделаю я лучше пару временных тест каталогов и всё протестирую "наживую"
Это сколько угодно. Почему ты тогда говоришь о юнит-тестах? Юнит-тесты - это совершенно определенная технология. Если хочешь тестировать все приложение, то можно использоваться BDD (например NBehave).
В приведенной версии, если я перемещаю каталог в директорию которая мониторится, возникает событие о создании объекта.
Код, где это происходит ты не приводил.
Если дофига файлов накидаю, могу ничего и не получить.
------
Тебе не нужно тестировать FileSystemWatcher.
Тебе нужно тестировать реакцию твоего приложения на то как он сработает при переполнении его очереди.
При какой-либо отсутствии реакции или отсустствии события ты все одно ничего не можешь сделать....
Вообще-то - указал - реагирует на копирование каталога
Б@*ть! Ошибка-то в чем? В том что сгенерировался эвент на каталог или в том, что был скопирован каталог? И где код, в котором происходит эта ошибка?
FileSystemWatcher.cs
А теперь просмотри топик и найти код из этого файла.
Ошибка-то в чем?
-----
Ошибка в том, что ватчер настроен на отслеживание создания файлов, а реагирует на них и на создание каталога.
В том что сгенерировался эвент на каталог или в том, что был скопирован каталог?
------
Тебе нужно поработать с FileSystemWatcher чтобы понимать возникающие проблемы.
Я, когда-то, считал что мне нужно мониторить некоторые изменения из студийного адд-она и потому его использовал - по-этому мне понятны проблемы Алекса. Самое смешное - тогда оказалось что мониторить ничего не надо...
А теперь просмотри топик и найти код из этого файла.
------
Зачем?
Ты спросил - Где именно возникает проблема? - Я дал тебе имя файла в котором находится этот код.
Файл - общедоступный. К нему, кстати, и тесты где-то были...
Ошибка в том, что ватчер настроен на отслеживание создания файлов, а реагирует на них и на создание каталога.
Т.е. баг в FileSystemWatcher?
Тебе нужно поработать с FileSystemWatcher чтобы понимать возникающие проблемы.
Нафига мне с ним работать?
Зачем?
Затем, что юнит-тестами покрывают СВОЙ код, чтобы быть уверенными в том, он удовлетворяет требованиям.
Т.е. баг в FileSystemWatcher?
-----
Скорее - фича. Надо в доках смотреть...
Нафига мне с ним работать?
-----
Чтобы не понимать об чем написано.
Затем, что юнит-тестами покрывают СВОЙ код, чтобы быть уверенными в том, он удовлетворяет требованиям.
-----
Угу...
Вот только для теста нужен мок, который должен отработать... как оригинальный код.
А чтобы его слепить - надо понимать/знать чего ожидать, включая ошибки и фичи...
Скорее - фича. Надо в доках смотреть...
Ну т.е. тестировать это не надо ;)
Вот только для теста нужен мок, который должен отработать... как оригинальный код.
Не должен.
А чтобы его слепить - надо понимать/знать чего ожидать, включая ошибки и фичи...
Ну, как ты сам говоришь, это надо смотреть в доках.
Тестируемая функция внутри кода работает исключительно с другими элементами кода, никогда не с файлами
Вполне может быть, "клеан юнит тест" правил я еще не учил. Тогда мне требуется что то другое, потому как большинство действий делается на уровне файловой системы и моделировать их смысла нет.
При этом, почти уверен что простая модель будет работать без проблем.
потому что ты ЗНАЕШь как он себя поведет
В том то и дело что не знаю, догадываться могу, но не знаю, как он будете себя вести во всех ситуациях. На сетевом диске например.
которые будут запускаться автоматически при каждом коммите
А отчего все должны запускаться при каждом коммите? Даже и на работе у нас было разделение, на ежедневные и после коммитные.
FileSystemWatcher как работал максимум с 80 файлами так и будет это делать
А я этого кстати, еще и не знаю, не проверял. Да и неизвестно как он себя поведет если время "выхода из эвента" будет долгим.
Ну и у меня на каждое сообщение запускался новый треад, а что будет когда они закончатся? Сейчас уже на ConcurrentQueue переделал с одним треадом
А если в системе есть уже такой каталог?
Маловероятно для случайно сгенерированного имени, но можно и еще раз сгенерить. Права должны дать.
После окончания теста каталог будет снесен вместе с содержимым?
Безусловно и свободное место будет проверяться. Корзина правда не будет чистится.
если делаешь учебное приложение, ты должен делать так, как надо.
Согласен, но в данном случае меня "поджимают сроки". Зачем мне инвестировать время в приложение которое идет на помойку.
Я свои юнит теста для парсера еще не окончил.
твой коллега будет сидеть и думать, что он сломал в системе
Ничего он думать не будет, у него будет сообщение с описанием проблемы. Типа "не могу создать тестовый каталог".
а не указал, что именно там не работает.
Может быть не очень подробно описал, но мне казалось что вполне достаточно.
https://foren.germany.ru/showmessage.pl?Number=37855570&Bo...
А гад реагирует на копирование каталога. _watcher.IncludeSubdirectories = false;
То бишь IncludeSubdirectories = false, из описания можно понять что этого достаточно для того чтобы извещение о добавлении нового каталога не приходило.
А оно приходит.
Очевидно, что если в _watcher был передан путь к директории
Так ему и нужен путь какую директорию мониторить.
Именно это и проверяют тесты, которые я привел в качестве примера.
Но так они это проверяют на основе знаний о файловой системе, а именно от этого хотелось вроде уйти. 
Затем, что ты почему-то решил писать юнит-тесты.
Это не я решил, для этой проги я бы их не делал. Но в задании было так.
NBehave
ну вот что то новое узнал
Код, где это происходит ты не приводил.
какой то класс был полностью, но и тех строчек что было вполне достаточно, там отсутствует только обработчик извещения, который просто транслирует его наверх.
а не указал, что именно там не работает.
Может быть не очень подробно описал, но мне казалось что вполне достаточно.
Из твоего описания было не понятно, что именно ты хочешь протестировать юнит-тестами. Собственно говоря, ты так до сиз пор и не ответил на этот вопрос. А значит рано еще приступать к написанию каких-либо юнит-тестов.
К сожалению, многие пренебрегают ответом на вопрос "что я хочу протестировать?". И пытаются фигачить тесты с установкой "чем больше, тем лучше" или "нам сказали писать тесты, мы и пишем".
Но так они это проверяют на основе знаний о файловой системе, а именно от этого хотелось вроде уйти.
Ну после нескольких сообщений я наконец понял, что FileSystemWatcher - это некий third party объект, а значит он работает правильно и тестировать его не надо. А ошибка у тебя была в инициализации.
Но если мы вернемся к тестированию, то значит тестировать тебе надо класс DirectoryWatcher, а для FileSystemWatcher сделать обертку. После этого ты просто сможешь эвент Created и проверять код хэндлера Watcher_Created. Никакие манипуляции с файловой системой для этого не будут нужны :)
какой то класс был полностью, но и тех строчек что было вполне достаточно, там отсутствует только обработчик извещения, который просто транслирует его наверх.
Те строчки, что ты привел - это просто инициализация. Впрочем, на инициализацию тоже можно легко написать тест :)
Собственно говоря, ты так до сиз пор и не ответил на этот вопрос
И не думаю что когда либо отвечу, в разрезе конкретно моего кода. Нет там никакой особой логики.
Нажали кнопу - появился диалог, взяли имя каталога для наблюдения
Нажали кнопу начали наблюдать за каталогом.
Кинули туда чего-то, пришло извещение, сделали какие то действия.
Всё самое интересное происходит на уровне файловой системы и во взаимодействии с кодом.
А ошибка у тебя была в инициализации.
Ну так именно это и хотелось проверить.
После этого ты просто сможешь эвент Created и проверять код хэндлера Watcher_Created.
Я и без этого могу проверять код хэндлера Watcher_Created ---_mainWorker.WorkOnNewItem(e);
Но там опять таки манипуляции с файлами, которые опять нужно как то имитировать. И имитация будет точно уж неполной.
Впрочем, на инициализацию тоже можно легко написать тест
ну и как это сделать не трогая файловую систему?
Ты потом сам написал, что один параметр не установил
Ну так это я нашел только после реального теста с файловой системой.
Это всё к тому что не нужно тестировать системные функции - они и так правильно работают.
Как бы я с виртуальными тестами не извращался никогда бы не нашел.