LINUX.ORG.RU

Много ли таких, кто юзает TDD или Test first?

 ,


1

4

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

А вы, что думаете по этому поводу, уважаемые.

Перемещено mono из talks

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

panter_dsd ★★★★
()

Я практикую TDD уже давно
но не видел реального человека... которые используют данную технологию

вывод: ты искусственный интеллект.

dimon555 ★★★★★
()
Ответ на: комментарий от dimon555

Может у него просто нет зеркал дома

anonymous
()

Прост надо без фанатизма.

Уже давно. У мну на проекте таких много :)

Если онли бизнесс требования присутсвуют - то и онли TDD.

Если есть что-то мок чего может обломать перфоманс и он (перфоманс) критичен - тут уже только функциональные тесты. Но опять же, ничто не мешает делать функциональное tdd, просто на интерфейс таким образом меньше ограничений накладывается.

Но ситуация настолько редка (таки виртуальные функи не такие уж и дорогие на практике), что единственный кейс когда я пренебрегаю сей практикой - это когда я прооценивался.

pon4ik ★★★★★
()

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

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

(c)

UVV ★★★★★
()
Ответ на: комментарий от vostrik

при чем тут автоматизация тестирования, если речь о TDD

Наверное при том, что TDD позволяет эту самую автоматизацию реализовать наиболее простым способом

monk ★★★★★
()
Ответ на: комментарий от UVV

Ага.

TDD - методология написания кода,построения архитектуры и частично документирования. Никакого отношения к QA эта методология не имеет

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

Спорный вопрос.

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

Ессно без функциональных тестов это мало эффективно.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Получившиеся артефакты, таки представляют ценность и для QA

разве что как документация

позволяют контролировать соглассованность интерфейсов,

разве что в test first. TDD предполагает написание девелопером юнит-тестов, которые кроме собственно кода (классов, функций) ничего не проверяют.

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

это количество в девелоперских тестах исчезающе мало. накладные расходы на анализ этих тестов в 90% случаев гораздо больше расходов на написание своих тестов

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

Зависит от области применения.

Вырожденный случай - api, для него это почти полные функциональные тесты.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

ну если система under test - исключительно интерфейс, то да. но в таком виде система в QA идёт очень редко, обычно вместе с интерфейсом тащится логика системы, а там уже от этих тестов толку пшик

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

Ну я к тому, что системы бывают разные, с разным количеством компонетов, взаимодействующих на разных уровнях стека.

Поэтому степень значимости выхлопа TDD процесса для оценки качества продукта - варьируется.

Но, даже как просто инструмент разработки, оно очень удобно :)

pon4ik ★★★★★
()
Ответ на: комментарий от vostrik

TDD предполагает написание девелопером юнит-тестов

Это с чего? Вообще отцы-основатели TDD всегда твердили, что TDD не обязательно на юнит-тестах строится. На любых, которые целесообразно писать.

dizza ★★★★★
()
Ответ на: комментарий от dizza

про «целесообразно» твердишь только ты, причем применительно ко всему - и к интеграционным тестам, и теперь вот к TDD. а вот Бек в своей книге о TDD говорит как раз о изолированных тестах. изолированный тест это (внезапно, да) и есть unit-test:


component: A minimal software item that can be tested in isolation.
component testing: The testing of individual software components. [After IEEE 610]
unit testing: See component testing.

vostrik ★★★☆
()
Ответ на: комментарий от dizza

Ога, оттуда и вышло bdd.

И если дают закладывать это в оценки - то это просто шик.

pon4ik ★★★★★
()
Ответ на: комментарий от vostrik

Интеграционный тест тоже может быть изолированный, в том смысле, что он изолирован от внешних ресурсов. И там есть две школы TDD, у них немного разные взгляды на эту тему.

dizza ★★★★★
()
Ответ на: комментарий от vostrik

про «целесообразно» твердишь только ты

Ну а ты упоролся по своей водопадовщине и дальше нее не видишь.

dizza ★★★★★
()
Ответ на: комментарий от dizza

Интеграционный тест тоже может быть изолированный

facepalm.jpg. ты хоть немного думаешь перед тем как писать?

И там есть две школы TDD, у них немного разные взгляды на эту тему.

«вторая школа TDD», которая предполагает acceptance тесты вместо unit тестов, давно имеет отдельное название BDD, и в нынешнем виде с TDD не имеет практически ничего общего

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

facepalm.jpg. ты хоть немного думаешь перед тем как писать?

Читай про mini-integration tests, неуч.

давно имеет отдельное название BDD

Что кто-то там придумал специальное название для чего-то там не отменяет факта что оно есть. Смирись.

dizza ★★★★★
()

TDD не нужен, если проект выкинуть на помойку, то тесты не нужны

если проект серьезный, то заказчик предоставляет тест кейсы и пишутся тесты

как то так

umren ★★★★★
()
Ответ на: комментарий от dizza

Читай про mini-integration tests, неуч.

кто-то там придумал не просто «специальное название для чего-то там», а название, противоречащее всем общепринятым названиям, а теперь напыщенный баран с лора называет меня неучем потому что я, видите ли, не в курсе их влажных определений. какая прелесть.

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

Что кто-то там придумал специальное название для чего-то там не отменяет факта что оно есть. Смирись.

в твоем манямирке BDD может и является еще одной ветвью TDD, но у адекватных людей это разные методологии.

vostrik ★★★☆
()
Ответ на: комментарий от vostrik

Никакого отношения к QA эта методология не имеет

Ну разве что отбирает у QA немного работы

redixin ★★★★
()
Ответ на: комментарий от panter_dsd

а если тест написан с кривой логикой, то классы получатся кривыми и застопорят разработку где-то на 100500 классе прямо перед дедлаином

unt1tled ★★★★
()
Ответ на: комментарий от unt1tled

ППКС. Тесты пишутся, когда уже есть спроектированная система классов/модулей. Для методов этих классов.

EnterpriseMobility
()
Ответ на: комментарий от yurikoles

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

EnterpriseMobility
()
Ответ на: комментарий от umren

TDD не нужен, если проект выкинуть на помойку, то тесты не нужны

/0. я нифига не понял.

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

Что будет тогда? У меня уже есть тесты. С кучей стабов под старое хранилище.

Как мен поступить, если нужно переписывать под новое?

EnterpriseMobility
()
Ответ на: комментарий от dizza

Чувак, а рассказать тебе про мини-интеграционные тесты уже проюнит-тестированных степов асинковского водопадика внутри юнит-теста?

Концепция вложенных друг в друга матриц сосет и причмокивает.

EnterpriseMobility
()
Ответ на: комментарий от panter_dsd

Дизайн сразу получается хорошо тестируемым.

Это да. Можно получить полное говно, зато хорошо тестируемое.

Vit ★★★★★
()
Ответ на: комментарий от pon4ik

Вырожденный случай - api, для него это почти полные функциональные тесты.

Ну то есть когда архитектуру дизайнить уже не надо, и от разработки остался только кодинг.

Vit ★★★★★
()
Ответ на: комментарий от Vit

Не надо путать тёплое с мягким.

TDD даёт возможность покушать кактус предлагаемый пользователю на этапе разработки, и если ты не верблюд, то дизайн правиться в соответвии с требованиями юзабилити (у нормального api, оно есть, да).

А ещё, оно, хорошо способствует реализации принципа «разделяй и властвуй».

Дизайн классов, да - никому не нужно. Важны только интерфейсы. И получаются при использовании TDD/BDD они на порядок лучше, чем если какой то динозавр только слезший с водопада надизайнил что то там.

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

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

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

Vit ★★★★★
()
Ответ на: комментарий от Vit

Если ты про гольные юнит тесты - полностью согласен. Но лично я генерализовал для себя концепцию tdd, до уровня требований, где в игру вступают функциональные, нагрузочные и интеграционные тесты.

Просто, если продукт - это api, то юнит тесты на публичные интерфейсы, есть одновременно и функциональные.

pon4ik ★★★★★
()
Ответ на: комментарий от dizza

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

vostrik ★★★☆
()
Последнее исправление: vostrik (всего исправлений: 1)
Ответ на: комментарий от EnterpriseMobility

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

vostrik ★★★☆
()
Ответ на: комментарий от pon4ik

Я конкретно про процесс дизайна архитектуры, а не то что вообще нужно при разработке. Тесты нужны, и иногда их удобно делать параллельно. Но к дизайну это боком.

Vit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.