На тему юнит тестов у меня оформилась еще одна мысль. Прошу покритиковать.

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

В индивидуальной разработке профита пока не узрел.

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

  


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

Не знаю, читали ли Вы, но есть способ экстремальной разработки (вроде так называется). Там Вы сначал пишите набор тестов к классу. А потом уже пытаетесь сделать так, чтобы Ваш класс успешно проходил все придуманные Вами тесты. Таким образом, Вы разрабатываете спецификацию (набор требований) к своему будущему классу и, соответственно, продумываете для чего этот класс предназначет и как его использовать. 
1). По идее, помогает лучше проектировать, продумывать классы и область их использования.
2). Код становится предсказуемым, т.к. выполняет предъявленные к нему требования.
3). Юнит-тесты можно в дальнейшем использовать как примеры к своему коду.
4). В будущем, если Вы захотите что-то поменять в классе, который используется в большом проекте, будет не так страшно это делать. Вам лишь нужно будет удовлетворить требованиям юнит-тестов. И это будет гарантировать Вам работу все системы без изменений.

Читал, использовал.
Если я правильно понимаю область применения этой методики - это методика ориентирована на быстрое получение результата, а не на обеспечение качества результата.

Почему? 
1). Прежде, чем начать писать реализацию класса, Вы продумываете его интерфейс. 
2). В юнит-тестах Вы формулируете требования, ограничения, возможности этого интерфейса.
=> Код получается предсказыуемым и контролируемым. Далее его можно легко изменять, не боясь за последствия в других частях системы. Это ли не качество кода?
Ну, и, если быть честным, выполнение этих двух пунктов довольно серьезная задача, которая по времени может занимать большую часть написания класса.

Athari, приятно познакомиться!   Вот оно как. А то не понятно было где Beltar нашел критика WPF дизайнера в рядах дотнетчиков....
Ну все, война продолжается.

Guinness, просто привычка и опыт. Вообще подход к разработке изменяется. Когда пишешь с тестами и без - он разный. При тестах уверенности больше, с самого начала. Быстрее первый результат (для экстремалов и заказчика). ...

Работай. Если бы я работал, то тоже бы писал на чем скажут. Но у меня есть возможность выбирать. У Атари, кстати, тоже есть, и его никто не заставляет изучить 100500 языков и технологий, которые могут через 5 лет быть всеми забыты, но если ему нравится.

А вообще я начинаю кое-что понимать, дело не только в фичах, дело в стадном инстинкте, когда человек заучил все новомодные штучки, но так и не научился разработке ПО, в итоге несмотря на все знания, появляются архитектурно ущербные и неработоспособные проекты. Все, теперь на вопрос "какой язык программирования надо учить?" мой ответ строго определен: "Идти на юриста", ибо сразу видно стремление приткнуться, а не писать программы.



Ну если я долго и качественно продумывал интерфейс класса, то, наверное, код предсказуем...
В общем мы уже насмотрелись на сферическое юнит-тестирование "Hello world"'ов в вакууме. Можно реальные примеры из реальных проектов и описание, конкретных случаев, когда был результат от тестирования?



Ровно как и любая другая "волшебная" методология.

Beltar, за всё надо платить.

Чем? Реализацию же Вы ещё не проверили. Это только первый шаг к предсказуемости.

Тут согласен, в интернете не сферических примеров я не находил. Однако, как можно придумать такой пример, чтобы объяснить некоторый принцип, который должен быть всем понятен? Вы же учебники по физике не ругаете за то, что они показывают Вам примеры на элементарных задачах, хотя в жизни все несколько сложней?
Я, например, тестировал парсер RTCM протокола таким образом. Хотя делал это не очень корректно. Но, в принципе, в дальнейшем помогло менять реализацию.

Кроме объектов базы и пары классов из JDBC драйвера там больше нет ничего специфичного. Так что не вижу проблем с запуском на обычной JDK.



Хочу сразу заметить у нас не TDD, но процесс тестирования поставлен очень хорошо:
- есть юнит тесты
- есть интеграционные тесты, от простейших - метод вызвался и вернул какой-то результат, проверки всего флоу - вызвали метод, проверили что данные проползли весь путь и появились в другой системе
- есть ручное и автоматическое тестирование через ГУЙ
- ну и финальное - тестирование бизнес аналитиками перед выкатом в прод

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

@Beltar

> Вот тебе не лень было сидеть и изучать весь дельфовый хелп?

1. Люблю холивары. Знай врага в лицо.
2. Таки была надежда на конкуренцию. МС актвино развивает те области, где есть сильные конкуренты.

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

Да, я понял, что это единственное, чего тебе не хватает для рисования обёрток к БД.

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

https://www.google.com/search?q=site:github...r+-%22cs+var%22

> Кстати, я еще не интересовался, не придется ли мне для полноценного применения этих методов выкурить весь курс работы с параллельными потоками

Для сложных приложений знать теорию и средства синхронизации надо. Для того, что нужно тебе ("чтобы UI не вис") достаточно "await Task.Run()".

> сейчас куда ни плюнь, везде контроли типов, сходный синтаксис, сходные возможности

Кроме дельфи. Собственно, об этом мой пост и был.

> Ну потрясающе, студийщиков наконец-то вытащили из компьютерного средневековья, теперь они спустя 18 лет после Delphi

1. Спустя 7 лет.
2. Историческая справка любопытна, но не представляет важности в текущей ситуации.

> Давай подумаем, что важнее, сдизайнить экзотический контрол, или возможность быстро собрать интерфейс на 10, а то и 100 формах.

Дотнет и джава предоставляют и первое, и второе. Дельфи -- только второе.

> При этом ты осмеливаешься наезжать на FMX, которой полтора года

WinForms и WPF рулили с первого релиза.

> а твою любимую студию допилить не могут уже несколько лет.

Что в ней хуже, чем в дельфи? Список.

> А Mono у меня вообще даже пустой GTk-проект не скомпилировала, запутавшись в своих же нейм-спейсах.

Это часом не *дельфи* не скомпилировала проект на моно? Моно тут не при чём.

> Delphi УГ просто потому, что она Delphi.

Дельфи УГ, потому что в ней всё хуже. Не надо перевирать слова.

> При этом, когда оказывалось, что в плюсах чего-то нету, то это во внимание не принималось.

Школьные годы ты вспомнил не к месту. Мы вообще-то дотнет и джаву обсуждаем. С плюсами отдельная история, он в другой нише и в другой весовой категории.

> Да и вообще мне от обилия инструментов как минимум становится страшно.

Вот теперь многое проясняется. Ты хочешь пользоваться дельфи, потому что она проста как топор, и ты её понимаешь. В новое и неизведанное соваться не хочется.

> Если тебе для вшивого сайта на месяц работы нужно 100500 инструментов, то, видимо, что-то не так с основным средством разработки.

Для простой разработки достаточно бесплатной VS Express без каких-либо инструментов. Всё остальное нужно, если ты выбираешься за рамки обёрток для БД.

> Отсюда и приколы с джавистами, которые год работали, самые передовые фреймворки использовали, а УГ вышло.

Этот интереснейший, очень познавательный и, без сомнения, невероятно поучительный пример я не читал. Частный пример -- не статистика.

> Ты сам сказал, что плюсы на 80% состоят из синтаксического маразма.

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

> Да и инфу по Delphi давно уже можно найти просто погуглив, все что можно спросить, уже давно спросили.

И новых вопросов, несмотря на регулярный выход новых версий, конечно, не возникает. К чему бы это?

> Перекрытием нескольких методов, каждый в одну строчку.

Для каждого типа списков. Кайф. Рай копипастера.

> Еще раз, ты раздуваешь каждое преимущество своего инструмента до совершенно невообразимых размеров, при этом не замечаешь огромных, как слон, недостатков.

Вот с этого места подробнее, пожалуйста. Я очень внимательно слушаю. Итак, какие у шарпа и джавы недостатки по сравнению с дельфи? Только умоляю, не надо опять про правосланые begin/end.

> Сишник сам не понял, как полностью расписался в том, что синтаксис Си с его вечными сокращениями никакой ясности не вносит, и надо дополнительно чего-то подсвечивать.

То есть для тебя не будет пользы в различном цвете для статических и нестатических членов? Ты это всё в уме держишь, так ведь? Ну да, что там в ему держать-то в обёртках для БД.

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

Кстати, в С++ можно пользоваться подобным синтаксисом). То ли у МакКонелла это было, то ли у Кернигана в книжке. Они прямо для Паскалистов показывали как можно настроить C++, чтобы он был похож на Паскаль.



Это к тому, что на github по крайней мере существует полмиллиона файлов с использованием var?

Для тебя использование юнит тестов -- "волшебная" методология? Как все запущенно.