Для задачи

https://foren.germany.ru/showmessage.pl?Number=37847327&Bo...

...

Остальное в следующем посте

Как то привык логику тестировать. А тут работа с файлами и системой.

Можно конечно всё тестовыми заглушками заменить, но не вижу большого смысла. Только для того чтобы тесты были...

Копируем допустим файл, на диске места больше нет.

Или скопировали десяток больших файлов. Или...

Это же целую модель системы надо делать.

А как проверить что реагирует только на файлы, а не на каталоги.

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

А вот времена и размеры будут роль играть.

Нужно определиться что и для чего. Юниттесты только защищают целостность и функтиональность кода.

Копируем допустим файл, на диске места больше нет.

Униттесты не проверяют состояния окружения, но они проверяют реакцию кода на определенные ответы опрошенного окружения. Сами запросы выполняют системные функции. Заменяем системную функциию на мок и симулируем ситуацию(вручную выбрасываем ошибкu). Проверяем реакцию собственного кода.

и обертки это моки

Не знаю что там в Яве и что имелось в виду. Я понимаю обвертку так.

    internal class DirectoryWatcher: IDirectoryWatcher
    {
        public event EventHandler<FileSystemEventArgs> NewFileAdded;
        private readonly FileSystemWatcher _watcher = new FileSystemWatcher();
        public void Start(string directoryName)
        {
            _watcher.Path = directoryName;
            // Watch files only.  
            _watcher.IncludeSubdirectories = false;
            // Watch all files.  
            _watcher.Filter = "*.*";
            _watcher.Created += Watcher_Created;
            //Start monitoring.  
            _watcher.EnableRaisingEvents = true;
        }
        public void Stop()
        {
            //Stop monitoring.  
            _watcher.EnableRaisingEvents = false;
        }
        private void Watcher_Created(object sender, FileSystemEventArgs e)
        {
            //e.FullPath
            NewFileAdded?.Invoke(sender, e);
        }
    }

Юниттесты нe проверяют перформанs

Так меня не скорость интересует, а функциональность. Просто в данном случае всё сильно зависит от количества и размеров файлов на входе.

Сейчас я всё делаю сразу после поступления события о приходе нового файла. А может нужно это всё в очередь записывать?

Ну и другое. Как проверить пароль перед стартом проги в юнит тестах. Дело в том что если ничего не делать, то прога просто не запуститься после запуска окна ввода пароля.

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

вручную выбрасываем ошибкu

Ну так это же все надо и делать вручную.

Но вот как проверить, что не будет сигнала от системы если я кинул в файл каталог?

Как то привык логику тестировать. А тут работа с файлами и системой.
Можно конечно всё тестовыми заглушками заменить, но не вижу большого смысла. Только для того чтобы тесты были...

Перед тем, как написать тест надо ответить на один вопрос - что я хочу протестировать?

Работу системных функций, которые работают с файлами тестировать не надо. Все эти функции уже 100500 раз протестированы и надо исходить из того, что они не содержат ошибок.

Значит у тебя есть некая логика, в которой есть некоторое количество вызовов системных функций. Ну а логику тестировать ты уже привык :) Осталось только абстрагироваться от системных вызовов. Сделать это можно одним простым способом - выделив эти функции на другой уровень и соеденив этот уровень со своим кодом через некий интерфейс (контракт).

Если не хочется городить все это ради тестов, то всегда можно сделать "системные тесты". Правда системные тесты а) медленнее и б) не могут протестировать все тонкости, например "на диске места больше нет" :)

Так что тут уж придется тебе делать выбор :)

Это же целую модель системы надо делать.

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

а функциональность. Просто в данном случае всё сильно зависит от количества и размеров файлов на входе.

Что изменится. если количество файлов увеличится в 10 раз? будет подключен другой обработчик? Изменится результат?

Как проверить пароль перед стартом проги в юнит тестах. Дело в том что если ничего не делать, то прога просто не запуститься после запуска окна ввода пароля.

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

То, что ты пытаешься запустить это интегратионтест в тестовом окружении. Если хрень запускается в броузере, работу юзера можно симулировать силениумоm

то всегда можно сделать "системные тесты".

Что такое системный тест?

надо ответить на один вопрос - что я хочу протестировать?

В данном случае написано надо

Работу системных функций, которые работают с файлами тестировать не надо.

А я и не хочу именно их тестировать, я могу просто неправильно задать параметры для их вызова.

выделив эти функции на другой уровень

ну они как бы и выделены. Но для тестов

1. нужно писать свою имплементацию
2. передавать ее в конструктор

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

Если хрень запускается в броузере

Эта хрень - обычное windows exe

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

Юниттесты не приносят пользу. Они защищают. Допустим есть код, этот код протестован вручную или другим способом и никогда не будет менятся. ВСЕ. Юниттесты никакой пользы больше не принесут.

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

У нас деятели повадились отключать ССЛ-шифрование у рест-ендпойнтов. Приложение стартует. Пока к нему кто то не попробует подконнектится. Закрыли юниттестами.

Что такое системный тест?

Тест всей системы. Т.е. запустил прогу, вбил пароль, сделал какие-то действия, проверил результат.

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

Во первых да. Часто написание Юниттестов сопоставимо с написанием кода. Во вторых если мы хотим от затычки особой функтиональности, то это уже спай - шпион.

я могу просто неправильно задать параметры для их вызова.

Не бывает неправильных параметров, бывают ответы системных функций. Честь из них это нормальные ответы, часть - сообщения о ошибках. Все эти варианты документируемы. Тестировать надо , как собственный код ресгирует на любой вариант ответа системной функции. То есть не "неправильные" или "правильные" параметры совать, а сразу моком выбрасывать необходимый для данного теста результат.

Если есть возможность формализовать утверждение, что такое "неправильный" параметр, то такой опработчик и его тест надо делать до вызова системной функциi

Что изменится. если количество файлов увеличится в 10 раз?

1. Копируем файл в каталог
2. Получаем уведомление о добавлении файла

• Сжимаем файл
• Перемещаем файл

пункт 2 занимает определенное время. И вся цепочка будет работать совершенно по разному в зависимости от количества и размера одновременно копируемых файлов.

Вот сейчас, например. В юнит тесте Зип работает без проблем, а обработчике выдает ошибку.

Юниттесты не приносят пользу. Они защищают.

А мне и не нужно ничего защищать. Я только хочу проверить работу проги на граничных условиях. Да и вообще что бы не сломал.

Вод делаю я XAML парсер, так у меня этих тестов на каждый чих: <tag>, <tag\r\n>, <\r\ntag> и т.п.

Явная польза.

А тут изменил не заглушку, а реальную обвертку и всё тебе уже поступают каталоги а не файлы.

пункт 2 занимает определенное время.

Это не функтиональность. Это производительность. Юниттесты не тестируют производительность.

И вся цепочка будет работать совершенно по разному

Если я правильно понял, то абсолютно также. Но дольше. Юниттесты это не тестируют. Они тестируют только принципиальные различия. Например допускается только 50 файлов. При наличии > 50 файлов должен сработать ДРУГОЙ кусок кода. Это принципиальное различие, это можно тестировать.

В юнит тесте Зип работает без проблем, а обработчике выдает ошибку.

Более того. У меня в реале зип выдаст ошибку, у соседа нет. Надо тестировать не зип. Нужно тестировать код, использующий зип. А зип выдавал и будет выдавать ошибки по независящим от кода причинам. Юниттесты тестируют только код.

В данном случае написано надо

И как, ответ-то уже есть? :)

А я и не хочу именно их тестировать, я могу просто неправильно задать параметры для их вызова.

Не понимаю.

ну они как бы и выделены. Но для тестов 1. нужно писать свою имплементацию 2. передавать ее в конструктор

1) определить интерфейс

2) сделать класс, который имплеметрирует этот интерфейс

3) передавать в конструктор можно и это пожалуй наиболее простое решение. Можно использовать какой-нибудь контейнер. Например Ninject. Но есть и другие способы.

Тестировать надо , как собственный код ресгирует на любой вариант ответа системной функции.

Так в том то и дело что никаких отличий не будет

sourceFilePath = "E:\\Alex\\WinCatalog" - каталог

sourceFilePath = "E:\\Alex\\WinCatalog" - файл

Это не функциональность. Это производительность.

reentrancy - производительность?

Если я правильно понял, то абсолютно также

Могу логов нафигачить если не веришь, хоть и не проверял еще

Нужно тестировать код, использующий зип.

и что тут тестировать FileCompressor.Compress(destFilePath); ?