Здравствуйте, gandjustas, Вы писали:

G>>>Тут именно и вопрос в том что стабильная часть кода должна быть определена заранее.
AVK>>Ты веришь в то, что это возможно?
G>Да, вполне бывает и так.

Ну, с верой не поспоришь.

G> Но редко и кода в таком "ядре" довольно мало.

Что редко? Стабильная часть определяется? Очень интересно.

AVK>>А если ошибся? Таки писать тесты после?
G>Также как и при написании с нуля, только с другими предположениями.

Не понял. Итак, у нас на каком то этапе сформировалась эволюционным путем (ага, TDD и agile частенько ходят парой) стабильная область. Как обеспечить ее покрытие тестами? Заранее покрывать тестами все подозрительные области, или все таки обеспечивать покрытие постфактум? Или просто забить?

Здравствуйте, AndrewVK, Вы писали:

G>>>> Там где SRP нарушается начинает расти количество тестов.
AVK>>>Магическим образом?
G>>Нет, вполне естественным. Нарушение SRP приводит к тому что варианты поведения множатся при увеличении тех самых обязанностей. Это фактически приводит к росту количества и сложности тестов.

AVK>Ничего не понятно. Давай по другому. SRP это, по сути, иначе сформулированное требование низкой связности и высокого зацепления.
Это демагогия, ни SRP, ни "требование низкой связности и высокого зацепления" формализовать невозможно. Кстати про связность у нас DIP.
Нарушения SRP можно по косвенным признакам выявить.

AVK>А вот с высоким зацеплением лично мне непонятно — каким образом тесты автоматично его обеспечивают?
Тесты сами по себе ничего не обеспечивают, но они являются отличным индикатором нарушения SRP.

Простые примеры нарушения SRP.
1) Класс фактически имеет несколько набора методов, которые не связаны друг с другом. Для всех них требуются некоторые внешние кассы, которые заменяются моками. По тестам видно что не везде подсовываются все моки или то что подсовываются пустые.
2)Класс сочетает в себе несколько слоев абстракции, некоторые методы класса реализованы через публичные методы того же класса. По тестам сразу видно что для разных методов получаются почти одинаковые тесты.
3)Класс имеет очень много обязанностей и реализует их все в одном методе. По тестам видно что проверяемые результаты не связаны между собой никак. Такой случай после рефакторинга превращается в сочетание 1) и 2)

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, gandjustas, Вы писали:

G>>>>Тут именно и вопрос в том что стабильная часть кода должна быть определена заранее.
AVK>>>Ты веришь в то, что это возможно?
G>>Да, вполне бывает и так.
AVK>Ну, с верой не поспоришь.
Хз, я вживую такое видел.

G>> Но редко и кода в таком "ядре" довольно мало.
AVK>Что редко? Стабильная часть определяется? Очень интересно.
Редко можно заранее стабильную часть выделить. Обычно это случается когда задача уже хорошо изучена.

AVK>>>А если ошибся? Таки писать тесты после?
G>>Также как и при написании с нуля, только с другими предположениями.

AVK>Не понял. Итак, у нас на каком то этапе сформировалась эволюционным путем (ага, TDD и agile частенько ходят парой) стабильная область. Как обеспечить ее покрытие тестами?
Она уже будет покрыта тестами, если вообще пишутся тесты. А если нет, то разговор ни о чем.

Здравствуйте, gandjustas, Вы писали:

AVK>>Ничего не понятно. Давай по другому. SRP это, по сути, иначе сформулированное требование низкой связности и высокого зацепления.
G>Это демагогия

Почему?

G>ни SRP, ни "требование низкой связности и высокого зацепления" формализовать невозможно

А вот приписывание мне утверждений, которые я никогда не делал — это демагогия. Где я писал хоть что то про формализацию?

G>. Кстати про связность у нас DIP.

Чего?

G>Нарушения SRP можно по косвенным признакам выявить.

И что?

AVK>>А вот с высоким зацеплением лично мне непонятно — каким образом тесты автоматично его обеспечивают?
G>Тесты сами по себе ничего не обеспечивают

Да? А началось все с утверждения, что, цитирую:

Тут вдруг неожиданно сам по себе реализуется SRP и прочий SOLID, и вообще ООП

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

Здравствуйте, gandjustas, Вы писали:

G>>> Но редко и кода в таком "ядре" довольно мало.
AVK>>Что редко? Стабильная часть определяется? Очень интересно.
G>Редко можно заранее стабильную часть выделить.

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

AVK>>Не понял. Итак, у нас на каком то этапе сформировалась эволюционным путем (ага, TDD и agile частенько ходят парой) стабильная область. Как обеспечить ее покрытие тестами?
G>Она уже будет покрыта тестами, если вообще пишутся тесты

Цитирую:

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

Откуда юнит-тесты возьмутся?

G>. А если нет, то разговор ни о чем.

Попробуй ответить на заданный вопрос. Я там три варианта привел — выбери какой нибудь или свой предложи.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, gandjustas, Вы писали:

AVK>>>Ничего не понятно. Давай по другому. SRP это, по сути, иначе сформулированное требование низкой связности и высокого зацепления.
G>>Это демагогия

AVK>Почему?

G>>ни SRP, ни "требование низкой связности и высокого зацепления" формализовать невозможно

AVK>А вот приписывание мне утверждений, которые я никогда не делал — это демагогия. Где я писал хоть что то про формализацию?

G>>. Кстати про связность у нас DIP.

AVK>Чего?

G>>Нарушения SRP можно по косвенным признакам выявить.

AVK>И что?

AVK>>>А вот с высоким зацеплением лично мне непонятно — каким образом тесты автоматично его обеспечивают?
G>>Тесты сами по себе ничего не обеспечивают

Единица текста на русском языке — одно предложение, иногда абзац. Комментируя по отдельности каждое слово конструктив только теряется.

AVK>Да? А началось все с утверждения, что, цитирую:
AVK>

AVK>Тут вдруг неожиданно сам по себе реализуется SRP и прочий SOLID, и вообще ООП

Это я писал? Что ты понял под фразой "сам по себе"? Магические преобразования кода?
Я всю фразу понимаю как "применение TDD подталкивает к принципам SOLID", это и согласуется с моим опытом.

А что ты хочешь доказать доказать?

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, gandjustas, Вы писали:

G>>>> Но редко и кода в таком "ядре" довольно мало.
AVK>>>Что редко? Стабильная часть определяется? Очень интересно.
G>>Редко можно заранее стабильную часть выделить.

AVK>Я бы сказал — практически никогда, если это не 100500-й проект на одну и ту же тему.
Я бы так не сказал.
Примеры:
1) бухгалтерия — счета, остатки, обороты. Над ними уже накручивается остальная логика.
2) Физический\графический движок
3) CMS
Это то, с чем я имел дело.

AVK>Тем интереснее становятся твои рекомендации, вырождающиеся, по сути, в рекомендации юнит-тесты делать только в случае "если ваш код сильно нетривиален и по интерфейсу реализация совсем не очевидна".
См примеры выше. Я сталкивался и сам разрабатывал подобные фреймворки. Довольно выгодно иметь в них хорошее покрытие тестами как success, так и failure.

AVK>>>Не понял. Итак, у нас на каком то этапе сформировалась эволюционным путем (ага, TDD и agile частенько ходят парой) стабильная область. Как обеспечить ее покрытие тестами?
G>>Она уже будет покрыта тестами, если вообще пишутся тесты

AVK>Цитирую:
AVK>

AVK>Если же код вашего модуля относительно простой, и\или часто подвержен изменениям из-за изменяющихся требований, и\или опирается на некоторый внешний функционал, то лучше не делать unit-тесты, а integration-тесты.

AVK>Откуда юнит-тесты возьмутся?
А я не говорю возьмутся. Пусть любые другие будут.

G>>. А если нет, то разговор ни о чем.
Ну если так считаешь, то и не стоило писать. Ты вместо конструктива пишешь непонятно что, засоряя тему ненужным текстом. Лучше бы что-нить по теме написал.

Здравствуйте, DorfDepp, Вы писали:

Подписываюсь под каждым сообщением gandjustas.

DD>...если они на практике ничего не ловят. Каждый метод будет прекрасно работать в изоляции, а упадет обязательно на нестыковке компонент, из-за старого формата данных в базе и т.п. Ради чего надо писать 10 минут метод и потом час-два к нему тесты, если пользы ровно ноль?
Я пишу юнит тесты только для сложной логики. Еще часто бывает, что тест написать намного проще чем логику. В таких случаях модульные тесты писать категорически рекомендуется.
Писать же юнит тесты для метода на 10 мин смысла не имеет никакого. Лучше написать интеграционный тест сразу на весь/все сценарии которые ты разрабатываешь в данным момент.

Юнит тесты так же сильно помогают при последующем рефакторинге или модификации класса в связи с изменившимися требованиями. Уузнать когда тесты понадобятся когда нет -- невозможно, но с опытом можно уже пытаться угадывать. С др стороны, сложная логика скорее всего (у меня) будет покрыта тестами, а простая или сложная но без тестов рефакториться с мыслями "сто раз так делал"


Примеры из моего опыта:
Пример сложной логики, тесты простые, но их достаточно много (14 штук):

	Скрытый текст
	Private _shiftPattern As ShiftPattern() = New ShiftPattern() {New ShiftPattern("A", "06:00", "14:00"), New ShiftPattern("B", "14:00", "22:00"), _ New ShiftPattern("C", "22:00", "06:00")} <Test()> _ Public Sub Can_Recognize_If_Current_Shifts_In_The_Middle() Dim mgr = New ShiftsManager(_shiftPattern, Function() Date.Parse("15:00")) Assert.That(mgr.PrevShift.Name, Iz.EqualTo("A")) Assert.That(mgr.CurrentShift.Name, Iz.EqualTo("B")) Assert.That(mgr.NextShift.Name, Iz.EqualTo("C")) End Sub <Test()> _ Public Sub Can_Recognize_If_Current_Shifts_Is_First() Dim mgr = New ShiftsManager(_shiftPattern, Function() Date.Parse("7:00")) Assert.That(mgr.PrevShift.Name, Iz.EqualTo("C")) Assert.That(mgr.CurrentShift.Name, Iz.EqualTo("A")) Assert.That(mgr.NextShift.Name, Iz.EqualTo("B")) End Sub '... <Test()> _ Public Sub Can_Calculate_Prev_Next_Shifts_Start_Stop_If_Current_Shifts_Is_Last_And_Time_Before_Midnight() Dim mgr = New ShiftsManager(_shiftPattern, Function() Date.Parse("23:00")) Assert.That(mgr.CurrShiftStart, Iz.EqualTo(Date.Parse("22:00")), "CurrShiftStart") Assert.That(mgr.CurrShiftEnd, Iz.EqualTo(Date.Parse("6:00").AddDays(1)), "CurrShiftEnd") Assert.That(mgr.PrevShiftStart, Iz.EqualTo(Date.Parse("14:00")), "PrevShiftStart") Assert.That(mgr.NextShiftEnd, Iz.EqualTo(Date.Parse("14:00").AddDays(1)), "NextShiftEnd") End Sub

Еще бывают случаи, когда логика простая, но ты знаешь, что тебе в ней ошибиться как два пальца. Например, я всегда путаюсь в кол-ве символов для substring (сколько символов вырезается или +-1?).
Для таких случаев у меня есть класс QuickTests с единственным пустым методом. Туда побыструхе пишется тест, прогоняется до "зелености" и тут же удаляется.

Есть случаи когда тест уж очень простой, логика -- отностиельно проста (смысл теста -- застраховать тебя от тупых ошибок). Пример -- нужно распарсить xml-ответ от внешнего сервиса. Тест написать элементарно (скопипастил ответ из браузера или SoapUI). Глупую ошибку сделать очень легко. Тест после прохождения либо удаляется либо остается для предотвращения ошибок регрессиии.


Это все что касается Юнит тестов. Есть еще примеры, но они совсем не "Юнит".

СУВ, Aikin

Здравствуйте, DorfDepp, Вы писали:

DD>...если они на практике ничего не ловят. Каждый метод будет прекрасно работать в изоляции, а упадет обязательно на нестыковке компонент, из-за старого формата данных в базе и т.п. Ради чего надо писать 10 минут метод и потом час-два к нему тесты, если пользы ровно ноль?

По моему опыту юнит тесты хороши при написании кода.
Я для себя пришел к выводу, что лучше всего писать одновременно и функционал и тесты к нему. Это способствует лучшему пониманию задачи и более четкому выделению контрактов классов (а это очень важно).
Писать же тесты полностью (например сразу несколько тестов для всего класса, при этом его контракт еще не до конца понятен) до написания кода плохо. Потому что на этапе поиска оптимального решения постоянно изменяются контракты, следовательно переписываются тесты.
Ну, и ошибки регрессии они тоже помогают отловить.

Здравствуйте, AndrewVK, Вы писали:

AVK>Да? А началось все с утверждения, что, цитирую:
AVK>

AVK>Тут вдруг неожиданно сам по себе реализуется SRP и прочий SOLID, и вообще ООП

Имелось ввиду, что проблемы со связностью и связанностью при написании тестов так и начинают сразу зиять, что сильно способствует написанию качественного кода сразу же. Без тестов для меня, например, эти проблемы часто неочевидны и всплывают только позже, при развитии проекта.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, michael_isu, Вы писали:

_>>Тут вдруг неожиданно сам по себе реализуется SRP

AVK>Это очень вряд ли. Unit-тесты, в лучшем случае, поспособствуют низкой связности. Но вот хороший уровень зацепления (и SRP, как следствие) автоматично из-за наличия тестов не получится.

Хороший уровень зацепления получится потому, что слишком уж много тестов придется написать, чтобы покрыть множество кейсов работы класса, если он большой и сложный, и когда эти тесты начинают писаться, то приходит понимание, что все это слишком сложно и трудоемко, это понимание _подталкивает_ выделять разные ответственности в разные классы, чтобы их проще было протестировать. В итоге — разные ответственности в разных классах и каждый из них сфокусирован на одной обязанности -> high cohesion.

Здравствуйте, gandjustas, Вы писали:

AVK>>Да? А началось все с утверждения, что, цитирую:
AVK>>

AVK>>Тут вдруг неожиданно сам по себе реализуется SRP и прочий SOLID, и вообще ООП

G>Это я писал?

Это то, на что отвечал я. И если ты в топик влез и решил что то другое пообсуждать — это уже твои проблемы.

Здравствуйте, gandjustas, Вы писали:

AVK>>Цитирую:
AVK>>

AVK>>Если же код вашего модуля относительно простой, и\или часто подвержен изменениям из-за изменяющихся требований, и\или опирается на некоторый внешний функционал, то лучше не делать unit-тесты, а integration-тесты.

AVK>>Откуда юнит-тесты возьмутся?
G>А я не говорю возьмутся.

Вот именно что не говоришь. А я именно об этом и спрашиваю уже третье сообщение.

G>Ну если так считаешь, то и не стоило писать. Ты вместо конструктива пишешь непонятно что, засоряя тему ненужным текстом. Лучше бы что-нить по теме написал.

Здравствуйте, Flem1234, Вы писали:

F>По моему опыту юнит тесты хороши при написании кода.
F>Я для себя пришел к выводу, что лучше всего писать одновременно и функционал и тесты к нему. Это способствует лучшему пониманию задачи и более четкому выделению контрактов классов (а это очень важно).
F>Писать же тесты полностью (например сразу несколько тестов для всего класса, при этом его контракт еще не до конца понятен) до написания кода плохо. Потому что на этапе поиска оптимального решения постоянно изменяются контракты, следовательно переписываются тесты.

+2. Требование писать тесты до кода — фактически приём заставить даже чрезмерно ленивых всё-таки сделать эти тесты, но это требование помогают против ленивых, а нормальным мешает.
Чуть подробнее об этом требовании и TDD в целом.

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Во-вторых, в TDD скорее функциональные тесты основную рояль играют, а не юнит.
N>>Это скорее справедливо для behavior-driven design (BDD)

AVK>Согласно википедии:
AVK>

AVK>It extends TDD by writing test cases in a natural language that non-programmers can read. Behavior-driven developers use their native language in combination with the ubiquitous language of domain driven design to describe the purpose and benefit of their code. This allows the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the business, users, stakeholders, project management, etc.

AVK>Так что вряд ли. BDD, получается, ближе к классическому водопадному подходу, где юзкейсы описываются на естественном языке или UML.

Ничего водопадного в процитированном куске нет, и в других нет. Водопад получается от совершенно независимого фактора — что описание необходимого функционала происходит гарантированно до разработки. В этом случае, да, ТЗ напрямую переводится в описание BDD и дальше не меняется. Но никто не требует от BDD, чтобы их описание не менялось. Сам по себе подход BDD родился в Agile (не хочу копать, в каком именно), а значит, сами спецификации необходимого могут корректироваться по необходимости. UML тут обычно ни при чём, а реально используется какой-то DSL, близкий к естественному языку. Тут, например, такой DSL строится поверх синтаксиса Ruby, но уже пригоден для написания тестером без глубокого знания языка.

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

AVK>Согласно википедии:
AVK>

AVK>Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.

AVK>Так что TDD все таки функциональные тесты предполагает в обязательном порядке. А unit уже по желанию.

Это с чего такой вывод? Во-первых, там нет ни слова про functional, integration или что-то подобное, там только test case. Во-вторых, если _a very short_ development cycle, то он должен повторяться на каждую функцию или небольшой модуль, а это само по себе предполагает юнит-тесты задолго до функциональных.

Да, граница между юнит-тестами и функциональными тестами нестрога; в некоторых случаях это одно и то же, как, например, при проверке относительно простой библиотечной функции. Но, например, для моей текущей работы эта разница в том, что юнит-тесты это проверка на коде, а функциональные — на живых процессах (запускается приложение, получает поток данных, отдаёт поток данных), и тут можно жёстко разделять их. Функциональные тесты являются основным проверяемым фактором для QA — наш QA про юнит-тесты ничего не знает, это дело программистов и меня как начальника группы программистов.

AVK> Что, помимо прочего, еще и логично, так как основная идея TDD состоит в описании ТЗ (то бишь функционала) в виде тестов,

Некорректный логический переход. ТЗ на функцию, да, описывает её функционал, но понятие функциональных тестов подразумевает проверку логически завершённого модуля, а не каждой функции (что даже мельче того "юнита", из которого родилось понятие unit testing).
TDD в распространённых описаниях требует, чтобы на каждое, требующее проверки (начиная с функции), рисовался тест до кода. Я уже упоминал идеологическую дырявость этого подхода, хотя если в твоём подчинении банда ленивых ламеров, он может оказаться единственным успешно работающим (к счастью, с таким пока не сталкивался).

AVK> что как раз таки функциональные тесты и обеспечивают, а никак не unit, которые зависят от конкретного, уже готового дизайна приложения. Скорее всего, попутал ты TDD с XP. Вот последнее как раз таки именно на unit-тестирование ориентировано.

Я ничего не путал, а твои методы парадоксальны — ты добавляешь предположения, нигде не описанные, и получаешь совершенно неожиданный результат. Непонятно, почему и зачем ты так делаешь.
Википедия, BTW, далеко не единственный источник. В описании этих методик я больше опирался на статьи с хабра, чем на википедию, и считаю это в данном случае более разумным.

N>>(Да, я понимаю, что у каждого свой источник знаний. Но я массово видел именно такое различие)
AVK>Википедия — достаточно массово?

Нет.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Pzz, Вы писали:

Pzz>>Говорят, они хороши, когда уже сильно потом класс ковыряешь. Подковырнул, тесты-то и посыпались, сидишь, чешешь репу

AVK>Когда сильно ковыряешь, unit-тесты очень плохи, так как висят свинцовой гирей и мешают проводить глубокий рефакторинг.
Тесты -- это код. Любой код висит свинцовой гирей, когда "сильно ковыряешь".

AVK> А толку от них никакого, так как они пачками становятся просто неактуальными на новом дизайне.
Мы все еще про юнит-тесты говорим? Тогда о каких пачках идет речь? (отвечать не нужно: Когда тестов много, они все равно разбиты на 2-3 группы внутри которых тесты похожи как близнецы -- менять их не сложно)

Юнит-тесты -- тесты на один класс. В основном. Даже если тестируется несколько классов, то всегда есть, скажем, так "центральный класс" (ЦК). Все остальные классы напрямую не тестируются, только через интерфейс "центрального класса".
Если требования влекут изменения интерфейса "центрального класса", то обычно достаточно подправить тесты в соответствии с новым интерфейсом. И все опять "зазелененло". В особо сложных случаях интерфейс и тесты меняются итеративно (в конце каждой итерации все должно "зеленеть").
Если же требования меняются "ну просто пипец", то, может, проще выкинуть нафик эту иерархию (начиная с ЦК) вместе с тестами и переписать заново?

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

Pzz>>А иначе придется еще и тесты ковырять, не только класс.
Pzz, вас же не смущает, что при изменении класса код соседних так же обычно приходится ковырять? Воспринимайте тесты как код. Полезный код. И все будет ОК.


СУВ, Aikin

Здравствуйте, AndrewVK, Вы писали:

Pzz>>Говорят, они хороши, когда уже сильно потом класс ковыряешь. Подковырнул, тесты-то и посыпались, сидишь, чешешь репу :-)
AVK>Когда сильно ковыряешь, unit-тесты очень плохи, так как висят свинцовой гирей и мешают проводить глубокий рефакторинг. А толку от них никакого, так как они пачками становятся просто неактуальными на новом дизайне.

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

Написание тестов — такая же работа, как и остальное, и должно быть распределено адекватно по реальной необходимости. Покрывать сплошным ковром юнит-тестов весь код — такая же нелепость, как и писать для функционального теста перебор, например, по третьей букве имени в акаунте — типа, а вдруг где-то что-то сработает не так. Но если есть кусок нетривиального кода в виде одной функции — на него нужен юнит-тест, и если этот код вылетит на следующем рефакторинге — селяви, но заранее плакаться по нему смысла не имеет. Где-то может быть ни одного юнит-теста — например, они вряд ли нужны для класса, который просто контейнер свойств без заметного набора данных. Где-то, наоборот, всё может быть ими покрыто в три слоя (у меня такие — математика, переработка данных, конверсия сложных структур). Где-то самые важные тесты — нагрузочные, а функционально тестировать нечего, или же нагрузочный тест включает в себя функциональный. Общего рецепта не будет (и ещё и потому плох TDD, что на некоторых случаях увеличивает работу в надцать раз без полезного выхлопа).

Pzz>>А иначе придется еще и тесты ковырять, не только класс.
AVK>Вот именно.

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

А есть ещё самоконтроль в рантайме и поддержка ручного контроля там же, но это отдельная тема.

Здравствуйте, gandjustas, Вы писали:

G>>>2)Unit-тесты абсолютно нет смысла писать после кода
G>>>Если вы создавая приложение выделяете некоторую стабильную часть кода, которую редко затрагивают при изменении требований, и которая используется другими частями приложения, то её нужно покрывать unit-тестами.
AVK>>Проблема только в том, что стабильность участков кода обычно определяется уже после их написания, что несколько противоречит твоему п.2.
G>Тут именно и вопрос в том что стабильная часть кода должна быть определена заранее. Как некоторый framework, на основе которого будет строиться приложение.

Здесь AndrewVK более прав: определение стабильной части кода заранее на практике скорее невозможно, а там, где возможно, она уже стабилизировалась давно (и обычно выглядит в виде библиотеки) и требует наличия тестов уже до текущей работы.

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

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

G>>>Если же код вашего модуля относительно простой, и\или часто подвержен изменениям из-за изменяющихся требований, и\или опирается на некоторый внешний функционал, то лучше не делать unit-тесты, а integration-тесты.
AVK>>Интеграционные тесты не делаются для отдельного модуля. По определению.
G>Да, они делаются для модуля и некоторого подмножества связанных с ним. Обычно для самого модуля+вызываемых модулей из низлежащих слоев.

Для меня это будет называться, скорее всего, функциональными тестами (а интеграционными будут проверки суммарной функциональности нескольких крупных блоков, не подчинённых друг другу, а работающими совместно).

Здравствуйте, AndrewVK, Вы писали:

G>>2)Unit-тесты абсолютно нет смысла писать после кода
G>>Если вы создавая приложение выделяете некоторую стабильную часть кода, которую редко затрагивают при изменении требований, и которая используется другими частями приложения, то её нужно покрывать unit-тестами.
AVK>Проблема только в том, что стабильность участков кода обычно определяется уже после их написания, что несколько противоречит твоему п.2.
Вот уж придрался так придрался. По остальным пунктам вопросов похоже нет.
Из сообщения ниже:
G>>Тут именно и вопрос в том что стабильная часть кода должна быть определена заранее.
AVK>Ты веришь в то, что это возможно?
Я, лично, верю в то, что не ошибатется только тот кто ничего не делает.

Давай поговорим не про тестирование, а про проектирование. Озвученый вопрос напрямую относится к проектированию.
При проектировании ты делаешь какие-то предположения и закладываешься на них. Если твои предположения окажутся ложными тебе придеться существенно менять архитектуру. Для борьбы с этим архитектуру дробят на компоненты. Если придет писец, то придется не все переписывать, а только один компонент. Чем опытнее архитектор, тем меньше приходится переписывать в случае чего.

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

G>>Если же код вашего модуля относительно простой, и\или часто подвержен изменениям из-за изменяющихся требований, и\или опирается на некоторый внешний функционал, то лучше не делать unit-тесты, а integration-тесты.
AVK>Интеграционные тесты не делаются для отдельного модуля. По определению.
Интеграционные тесты тестируют в том числе и конкретные модули. Именно это хотел сказать и сказал gandjustas.

СУВ, Aikin

Здравствуйте, netch80, Вы писали:

AVK>>Так что TDD все таки функциональные тесты предполагает в обязательном порядке. А unit уже по желанию.

N>Это с чего такой вывод? Во-первых, там нет ни слова про functional, integration или что-то подобное, там только test case.

С того, что "test case that defines a desired improvement or new function" это функциональный тест. По определению:

Functional testing refers to activities that verify a specific action or function of the code. These are usually found in the code requirements documentation, although some development methodologies work from use cases or user stories. Functional tests tend to answer the question of "can the user do this" or "does this particular feature work."

N>Да, граница между юнит-тестами и функциональными тестами нестрога; в некоторых случаях это одно и то же, как, например, при проверке относительно простой библиотечной функции. Но, например, для моей текущей работы эта разница в том, что юнит-тесты это проверка на коде, а функциональные — на живых процессах (запускается приложение, получает поток данных, отдаёт поток данных)

Тестирование на живых процессах, когда запускается приложение целиком, это интеграционное тестирование. Функциональное точно так же тестирует в основном отдельные модули. Разница с unit в том, что последнее тестирует все аспекты контракта, а функциональное проверяет работоспособность модуля на предполагаемых юзкейсах. Т.е. unit-тестирование проверяет соответствие контракта спецификации, а функциональное — соответствие функционала входному ТЗ.

N>Функциональные тесты являются основным проверяемым фактором для QA — наш QA про юнит-тесты ничего не знает, это дело программистов и меня как начальника группы программистов.

Это вопрос организационный, к разделению на юнит и функциональное это никакого отношения не имеет. Функциональные тесты очень часто пишутся именно программистами.

N>Некорректный логический переход. ТЗ на функцию, да, описывает её функционал, но понятие функциональных тестов подразумевает проверку логически завершённого модуля

Ничего подобного оно не подразумевает. См. определение.

N>Википедия, BTW, далеко не единственный источник.

О да, знакомо. Если что то не стыкуется — виновата википедия.
Не, она, конечно, далеко не единственный и даже не самый авторитетный источник, но если выбирать между ней и твоими голословными заявлениями, то я предпочту первое.

N> В описании этих методик я больше опирался на статьи с хабра

О! Зашибись источник. Все с вами ясно.

N>, чем на википедию, и считаю это в данном случае более разумным.

Считай.

AVK>>Википедия — достаточно массово?
N>Нет.