ты определись, что тебе нужно.

На каждом шаге разное

Для начала мне нужно рабочее приложение.

Затем среда для его тестирования.

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

А прога в итоге и не работает всегда правильно.

Если бы у приложения была бы какая-то нетривиальная логика, то еще какой то смысл был бы. А так, просто последовательность шагов: сжать и переместить.

Но всё завязано именно на манипуляциях с файловой системой, которую трогать низзя.

На крупной фирме с сотней программистов

Сорри, с такими еще не сталкивался и думаю что уже и не получится. Чтобы целая сотня над чем то одним работала.

Но в твоем случае (я не программирую на шарпе) на яве это элементарно

Не вижу особой разницы в языках, но и элементарности тоже не вижу.

В шарпе ексцепшионы есть?

Естественно. Я вот только не слышал что в Яве WPF есть.

Ну вот если устройство мне посылает дату 30.02.2021 - это как класифицировать?

и при этом не понял

------

Ну так разъяснил бы. На доки не кивай - там описание с проблеммами.

А то Я эту фигню пытался использовать года 4 назад и уже подзабыл.

Что вспоминал - пояснял.

Вот про поведение буфера - не помню - никогда не сталкивался...

Ну так разъяснил бы.

В этом топике уже все объяснено. Но боюсь, что ни ты, ни AlexNek просто не хотите понимать.

Так что изучайте сами :) А если появятся вопросы, то велком :)

Ну вот если устройство мен

Я не понял предложение что значит "устройство мен"

Спасибо, исправил

Ну вот если устройство мне посылает дату 30.02.2021 - это как класифицировать?

просто не хотите понимать.

мы не первые и не последние

Recently there’s been some discussion in the community about a long-held belief regarding unit tests: A unit test should not touch the filesystem.

https://www.leadingagile.com/2017/12/should-unit-tests-tou...

Ага. Первой беды не только в России, по всему миру на 100 лет вперёд припасено. Автора этого бложика явно припасли с запасом.

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

Если вы хотите тестировать стороннюю библиотеку - пожалуйста, ради бога. Но называйте эти тесты как минимум "интеграционными". Хотите протестировать скорость выполнения? Нет преграды патриотам. Но не называйте это юнит-тестом. Назовите "нагрузочным тестом".

Понимаете?

Но не называйте это юнит-тестом

Да один фиг как назвать, главное что бы был польза.

Да один фиг как назвать, главное что бы был польза.

Нет. Как раз очень важно. Юниттест это не просто технология, позволяющая запустить кусок кода без создания полного контекста приложения. Это еще и технология, которая применяется в определенных местах. Строго определенных. Именно поэтому юниттест с определенным кодом вызавает недоумение - он просто не лезет в эти самые места. То ты и не собираешься его туда пихать. У тебя другие цели.В результате мы перепинаемся уже под сотню постов на ровном месте.

Вопрос определениj и основанного на них понимания.

Да один фиг как назвать, главное что бы был польза.

Садись, два! (c)

- Тема: велосипед, чтобы ездить на работу

- А в чём проблема?

- Мне до работы 150 км в одну сторону

- Тогда, наверное, нужен не велосипед а машина? Или на велосипеде доезжать только до вокзала?

- Какое гавно эти ваши велосипеды, а все рассказывают что только на них надо ездить

- Так может всё же нужна машина?

- Один фиг как называть, лишь бы на работу доехать.

Звучит глуповато, не?

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

Может всё же определиться для начала что же тестировать надо

По историческим причинам было наоборот

Согласно условию задачи требовались юнит тесты. Но как оказалось, они смысла особого не имеют в данном случае.

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

Для "поиграться" всё слишком много по времени. По крайней мере, нашел проблемы и чему то научился.

Мне бы лучше приложение из Azure на свой сервер перекинуть, хоть абонплату сэкономил бы.

Согласно условию задачи требовались юнит тесты. Но как оказалось, они смысла особого не имеют в данном случае.

Из моего опыта последних 10 лет - юнит тесты нужны всегда если проект должен жить дольше 6 месяцев. И смысл в них есть. Даже для геттера надо писать тест. Потому что уже не раз и не два были очепятки. А потом - ой, а чего это мы вместо 16 потоков используем 62342? А перепутали. Закопипейстелись. При инициализации менеджера uid пользователя из параметра конструктора записали и в поле uid и в поле maxThreads.

А чтобы найти эту примитивную ошибку, тратишь не минуту и не час. А потом еще и задеплой всё заново.

если проект должен жить дольше 6 месяцев.

А если проект будет жить 0 часов, 0 минут?

Для того чтобы написать ЮТ согласно академическим канонам, нужно перелопатить всё приложение, написать штуки три тестовых заглушки, а потом еще думать как смоделировать возможные ошибки.

При этом для разработки они мне почти бессмысленны.

Вот в другом проекте, где дофига логики, там без них и шагу ступить невозможно.

А если проект будет жить 0 часов, 0 минут?

То даже код проекта можно не писать.

Для того чтобы написать ЮТ согласно академическим канонам, нужно перелопатить всё приложение, написать штуки три тестовых заглушки, а потом еще думать как смоделировать возможные ошибки.

Сложность написания юнит-тестов - хороший индикатор дерьмовости кода.

Сложность написания юнит-тестов - хороший индикатор дерьмовости кода.

не всегда. Вот что тут дерьмового?

compressor.CompressFile(sourceFile);

mover.MoveFile(sourceFile, desctinationFile)

Практически всегда. В 95% случаев.

В приведённом коде проблем нет, но для него и юнит-тесты написать совершенно несложно. Делаем моки для copressor и mover и вперёд.

Делаем моки для copressor и mover и вперёд.

Может быть я еще неправильно представляю себе как делать моки?

Для меня - это написать два тест враппера и передать их вместо реальных.

Как именно делать моки - дело вкуса. Сегодня глупо не использовать для этого библиотеки. Я честно говоря не знаю что сейчас для шарпа есть, лет 5 назад даже easymock.net был, не знаю, может и жив ещё.

Главное чтобы с минимальными усилиями было получить реализацию интерфейса ICompressor (пусть он так называется), у которой мы определяем ТОЛЬКО метод CompressFile. А все остальные 20 методов нам глубоко не интересны. И для разных тестов определяем поведение этого метода:

1. что-то нам нужное вернёт (строку, код состояния, мок объекта)

2. вернет что-то неправильное (пустую строку, неизвестный код, нуль)

3. бросит исключение

И проверяем что наш код всё это правильно переварит.

Ну вот вроде популярная либа Moq

https://habr.com/ru/post/150859/

Всё что она может сэкономить - это не писать заглушку.

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

То бишь в "главный класс" нужно передать минимум 3 совершенно не нужных параметра, а с экспортом и 4. Соответственно и количество лишних интерфейсов возрастает.

В общем, KISS - пошел нафиг.

Ну и как проверить конкретные имплементации интерфейсов вопрос остается открытым.

Например, как проверить, что когда компрессор создает файл, то этот файл будет игнорироваться обозревателем каталога. Хотя, даже как это проверить можно и что то придумать, а вот как до этого "дойти" в тестовой системе не имею представления.