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

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

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

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

:D почему это?

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

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

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

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

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

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

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

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

(c)

я так и знал )))

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

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

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

ерунда. TDD ортогонально тестированию вообще и его автоматизации в частности

TDD ортогонально тестированию вообще

Шта?

Ага.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

про «целесообразно» твердишь только ты, причем применительно ко всему - и к интеграционным тестам, и теперь вот к 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

как то так

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

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

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

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

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

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

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

Ты путаешь изолируемость с модульностью.

Бешено люто неистово плюсую

Т.е. параллельно?

мну
перфоманс
функи
кейс
прооценивался

Здравствуйте, это Русская информация об ОС Linux?

А в чем разница?

Можешь объяснить своими словами, как относится TDD к дизайну классов?

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

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

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

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

тогда не

классов

, а класса. Одного.

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

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

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

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

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

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

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

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

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

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

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

Чё ет?

У тебя какое то странное представление об api.

Ага. Я еще программистов по рукам бью, когда вместо дизайна dataflow лепят дизайн классов.

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

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

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

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

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

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

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

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

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

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

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