Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaptevVV, Вы писали:
LVV>>Рассмотри проблему с обратного конца. LVV>>Прежде, чем писать текст метода, напиши, как ты будешь этот метод использовать. LVV>>Это и будут unit-тесты. LVV>>Это — не тестирование. Это разработка (через тестирование).
AVK>Во-первых, TDD и юнит-тесты, это вовсе не одно и то же. AVK>Во-вторых, в TDD скорее функциональные тесты основную рояль играют, а не юнит.
Это скорее справедливо для behavior-driven design (BDD), там основные тесты — именно функциональные на целевые действия. А TDD такого ограничения не предполагает, скорее наоборот — в полном виде оно требует такого контроля на мельчайшие детали разработки.
(Да, я понимаю, что у каждого свой источник знаний. Но я массово видел именно такое различие)
Здравствуйте, netch80, Вы писали:
N>хорошо и подробно объясняется, как превратить такой код в легко проверяемый, вплоть до того, что всё покрывается юнит-тестами. А если вы этого не делаете, то таки да, легко не будет.
Не скажу, что сейчас все трудно. Но часто ошибки в том, что алгоритм (улучшение) просто не решает поставленную задачу, хотя он реализован без ошибок в точности, как было задумано. Потому что находится некий неучтенный набор входных данных.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, netch80, Вы писали:
N>>хорошо и подробно объясняется, как превратить такой код в легко проверяемый, вплоть до того, что всё покрывается юнит-тестами. А если вы этого не делаете, то таки да, легко не будет.
M>Не скажу, что сейчас все трудно. Но часто ошибки в том, что алгоритм (улучшение) просто не решает поставленную задачу, хотя он реализован без ошибок в точности, как было задумано. Потому что находится некий неучтенный набор входных данных.
И такое бывает, сплошь и рядом. Но это не значит, что тестировать не надо или что не надо стараться делать систему пригодной к тестированию.:)
Здравствуйте, netch80, Вы писали:
AVK>>Во-вторых, в TDD скорее функциональные тесты основную рояль играют, а не юнит.
N>Это скорее справедливо для behavior-driven design (BDD)
Согласно википедии:
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.
Так что вряд ли. BDD, получается, ближе к классическому водопадному подходу, где юзкейсы описываются на естественном языке или UML.
N>, там основные тесты — именно функциональные на целевые действия. А TDD такого ограничения не предполагает, скорее наоборот — в полном виде оно требует такого контроля на мельчайшие детали разработки.
Согласно википедии:
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.
Так что TDD все таки функциональные тесты предполагает в обязательном порядке. А unit уже по желанию. Что, помимо прочего, еще и логично, так как основная идея TDD состоит в описании ТЗ (то бишь функционала) в виде тестов, что как раз таки функциональные тесты и обеспечивают, а никак не unit, которые зависят от конкретного, уже готового дизайна приложения. Скорее всего, попутал ты TDD с XP. Вот последнее как раз таки именно на unit-тестирование ориентировано.
N>(Да, я понимаю, что у каждого свой источник знаний. Но я массово видел именно такое различие)
Википедия — достаточно массово?
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
Здравствуйте, Pzz, Вы писали:
Pzz>Говорят, они хороши, когда уже сильно потом класс ковыряешь. Подковырнул, тесты-то и посыпались, сидишь, чешешь репу
Когда сильно ковыряешь, unit-тесты очень плохи, так как висят свинцовой гирей и мешают проводить глубокий рефакторинг. А толку от них никакого, так как они пачками становятся просто неактуальными на новом дизайне.
Pzz>А иначе придется еще и тесты ковырять, не только класс.
Вот именно.
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
Может я неправильно все делаю, но именно юнит-тестами удобно отлаживать сколь-нибудь сложную логику.
Ну а потом они просто остаются. Есть пить почти не просят.
Здравствуйте, HolyNick, Вы писали:
HN>Я сам не писал до сих пор тесты. Но в ходе работы были мысли о том, когда они могут сыграть роль. HN>Например, ты разрабатываешь большой класс, с большим функционалом и что самое главное взаимосвязями. HN>Через некоторое время становится тяжело держать в голове все эти взаимосвязи и соответственно ты не осознаешь в каком месте новая фича вызовет некорректную работу предыдущего кода. В это случае ты вызываешь свой набор(их может быть много) тестов и проверяешь не уронили ли твои новые две строчки кода твой класс в месте, который ты написал месяц назад (и потестил). При условии отсутствия тестов, тебе на каждые новые две строчки кода придется заново все тестировать вручную, что в некоторых случаях проблематично или очень проблематично или невозможно. HN>Если ты пишешь кнопочку, то тестировать ее сильно не надо, а вот если пишешь софт для самолета, то тут цена ошибки сам понимаешь высока. И возможно набор тестов сможет уберечь от ошибки. Гарантии 100 процентов конечно нет.
Тесты большей частью нужны не для того, чтобы проверять не упал ли твой код где-то при рефакторинге, а чтобы сделать хороший дизайн приложения. С тестами как раз будет слабосвязанный код, чистый и понятный, иначе тесты не напишутся. Например, нужно написать алгоритм обработки чего-то, то вместе того, чтобы внутри этого класса ложить помимо логики работу с бд, сетью, валидацию, использование других компонентов/сервисов, ты делаешь небольшой класс, который делает что-то конкретное, и за другим функционалом лезет в другие классы, а кто там — реальный ли класс или мок — это уже не его забота. Тут вдруг неожиданно сам по себе реализуется SRP и прочий SOLID, и вообще ООП, т.к. класс делает только то, что должен делать, и ничего больше.
Попробуйте покрыть тестами свой проект, много интересного о его дизайне поймете
Здравствуйте, DorfDepp, Вы писали:
DD>...если они на практике ничего не ловят. Каждый метод будет прекрасно работать в изоляции, а упадет обязательно на нестыковке компонент, из-за старого формата данных в базе и т.п. Ради чего надо писать 10 минут метод и потом час-два к нему тесты, если пользы ровно ноль?
Сколько заблуждений в таком коротком тексте...
1)Unit-тесты ловят очень хорошо баги регрессии. Когда в следствии рефакторинга или других манипуляций с кодом меняется его поведение, а не должно
2)Unit-тесты абсолютно нет смысла писать после кода, после кода стоит писать интеграционные тесты, которые как раз будут взаимодействие компонент проверять
3)Польза от unit-тестов огромная, так как правильно написанные тесты помогают проверять корректность кода очень быстро не выходя из из среды разработки.
4)Но unit-тесты — тоже код, который надо поддерживать и меня в случае изменений требований, это дает оверхед, иногда весьма значительный.
Если вы создавая приложение выделяете некоторую стабильную часть кода, которую редко затрагивают при изменении требований, и которая используется другими частями приложения, то её нужно покрывать unit-тестами.
Если ваш код сильно нетривиален и по интерфейсу реализация совсем не очевидна, то также unit-тесты вам помогут.
Если же код вашего модуля относительно простой, и\или часто подвержен изменениям из-за изменяющихся требований, и\или опирается на некоторый внешний функционал, то лучше не делать unit-тесты, а integration-тесты.
AVK>Так что TDD все таки функциональные тесты предполагает в обязательном порядке. А unit уже по желанию. Что, помимо прочего, еще и логично, так как основная идея TDD состоит в описании ТЗ (то бишь функционала) в виде тестов, что как раз таки функциональные тесты и обеспечивают, а никак не unit, которые зависят от конкретного, уже готового дизайна приложения. Скорее всего, попутал ты TDD с XP. Вот последнее как раз таки именно на unit-тестирование ориентировано.
В TDD/BDD используется несколько уровней тестов и пишутся они outside-in — от end-to-end/acceptance через integration к unit. Пишем красный end-to-end/acceptance тест, описывающий (тестирующий) фичу (cucumber, fitnesse и т.д.), он показывает откуда идти и какой ожидается результат. Далее строим дизайн с помощью unit/integration тестов, начиная с причины (ui, сообщение в сервис пришло, появилась запись в логе и т.п.) и заканчивая результатом (запись в базе, послали сообщение сервису, записали в лог и т.п.). Естественно, рефакторим в процессе и когда end-to-end зеленый. Работает отлично. Некоторые отделяют TDD (только модульные тесты) от ATDD/BDD (TDD + acceptance tests), но суть это не меняет.
Здравствуйте, -VaS-, Вы писали:
VS>В TDD/BDD используется несколько уровней тестов
Используются. Но обязательны в TDD только функциональные.
VS> и пишутся они outside-in — от end-to-end/acceptance через integration к unit. Пишем красный end-to-end/acceptance тест, описывающий (тестирующий) фичу (cucumber, fitnesse и т.д.)
Можно по русски?
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
Здравствуйте, michael_isu, Вы писали:
_>Тут вдруг неожиданно сам по себе реализуется SRP
Это очень вряд ли. Unit-тесты, в лучшем случае, поспособствуют низкой связности. Но вот хороший уровень зацепления (и SRP, как следствие) автоматично из-за наличия тестов не получится.
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
Здравствуйте, gandjustas, Вы писали:
G>2)Unit-тесты абсолютно нет смысла писать после кода
G>Если вы создавая приложение выделяете некоторую стабильную часть кода, которую редко затрагивают при изменении требований, и которая используется другими частями приложения, то её нужно покрывать unit-тестами.
Проблема только в том, что стабильность участков кода обычно определяется уже после их написания, что несколько противоречит твоему п.2.
G>Если же код вашего модуля относительно простой, и\или часто подвержен изменениям из-за изменяющихся требований, и\или опирается на некоторый внешний функционал, то лучше не делать unit-тесты, а integration-тесты.
Интеграционные тесты не делаются для отдельного модуля. По определению.
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>2)Unit-тесты абсолютно нет смысла писать после кода
G>>Если вы создавая приложение выделяете некоторую стабильную часть кода, которую редко затрагивают при изменении требований, и которая используется другими частями приложения, то её нужно покрывать unit-тестами.
AVK>Проблема только в том, что стабильность участков кода обычно определяется уже после их написания, что несколько противоречит твоему п.2.
Тут именно и вопрос в том что стабильная часть кода должна быть определена заранее. Как некоторый framework, на основе которого будет строиться приложение.
G>>Если же код вашего модуля относительно простой, и\или часто подвержен изменениям из-за изменяющихся требований, и\или опирается на некоторый внешний функционал, то лучше не делать unit-тесты, а integration-тесты.
AVK>Интеграционные тесты не делаются для отдельного модуля. По определению.
Да, они делаются для модуля и некоторого подмножества связанных с ним. Обычно для самого модуля+вызываемых модулей из низлежащих слоев.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, michael_isu, Вы писали:
_>>Тут вдруг неожиданно сам по себе реализуется SRP
AVK>Это очень вряд ли. Unit-тесты, в лучшем случае, поспособствуют низкой связности. Но вот хороший уровень зацепления (и SRP, как следствие) автоматично из-за наличия тестов не получится.
Если бы делал TDD то знал бы что жто так и есть. Там где SRP нарушается начинает расти количество тестов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Если бы делал TDD то знал бы что жто так и есть. AVK>Намекаешь на мою некомпетентность? А если без перехода на личности?
Уверен что ты не юзал TDD по полной программе в реальном проекте.
G>> Там где SRP нарушается начинает расти количество тестов. AVK>Магическим образом?
Нет, вполне естественным. Нарушение SRP приводит к тому что варианты поведения множатся при увеличении тех самых обязанностей. Это фактически приводит к росту количества и сложности тестов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Тут именно и вопрос в том что стабильная часть кода должна быть определена заранее. AVK>Ты веришь в то, что это возможно?
Да, вполне бывает и так. Но редко и кода в таком "ядре" довольно мало.
G>> Как некоторый framework, на основе которого будет строиться приложение. AVK>А если ошибся? Таки писать тесты после?
Также как и при написании с нуля, только с другими предположениями.
Здравствуйте, gandjustas, Вы писали:
G>>>Если бы делал TDD то знал бы что жто так и есть. AVK>>Намекаешь на мою некомпетентность? А если без перехода на личности? G>Уверен что ты не юзал TDD по полной программе в реальном проекте.
Так, вежливый намек не понят. Тогда более прозрачно — заканчивай демагогию с переходом на личности. Есть что сказать по теме — говори, а компетенцию мою обсуждать не стоит, она, как минимум, не хуже твоей. И, внезапно, это еще и правилами форума запрещено.
G>>> Там где SRP нарушается начинает расти количество тестов. AVK>>Магическим образом? G>Нет, вполне естественным. Нарушение SRP приводит к тому что варианты поведения множатся при увеличении тех самых обязанностей. Это фактически приводит к росту количества и сложности тестов.
Ничего не понятно. Давай по другому. SRP это, по сути, иначе сформулированное требование низкой связности и высокого зацепления. С тестами и низкой связностью более менее понятно — тесты требуют формализации контрактов окружения, чтобы заткнуть внешний функционал моками. В результате это приводит к устранению некоторых видов высокой связности (не всех, но тем не менее). А вот с высоким зацеплением лично мне непонятно — каким образом тесты автоматично его обеспечивают? Попробуй объяснить без упоминания моей квалификации и прочей демагогии.
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
