Это основная методология мидл-девелоперов. Среднячки такие среднячки. Код пишут, но заезд с неба не хватают.

но ведь тесты - это тоже код!

Я просто оставлю это здесь:

Тестируемость

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

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

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

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

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

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

Модульные тесты из QA != юнит-тесты в TDD. Выше речь как раз про модульные тесты

выше - это где? В моей копипасте из Марка Симана?

да.

Test Driven Development - это Тестирование Через Разработку? КАКСТРАШНОЖЫТЬ.

Зато работает. В отличие от.

Не путай девелоперов с менеджерами.

При чём здесь менеджеры? Менеджеры и слов то таких не знают - TDD.

Менеджеры и слов то таких не знают - TDD.

Это хорошо, если не знают. Меньше будут мозг сношать.

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

Обсуждение на 3 страницы это уже на TDD мало похоже. Это уже похоже на TalkDD ...

Все должно быть легко, просто и понятно. Например: это задачи, а это просто тесты как минимум для начала.

Внезапно нет.
обратно нет

аргументация уровня ioway

Волнует. Это первый критерий качества реализации.

критерий качества реализации - соответствие реализации требованиям. всё. фичреквесты к реализации отношения не имеют.

И проектирования? И реализации?

и проектирования, и реализации

Найди в оригинальной фразе «включающий в себя полный комплекс мер от автоматическоко тестирования до ручного» аббревиатуру UI. Нету? А с какого перепугу ты его сюда приплел?

в твоем манямирке UI - это то, что не тестируется? или то, что «без тестирования представления в получится говно»?

И качество чего она проверяет?

качество требований, качество процессов, соответствие стандартам. всего.

Твои слова «автоматическое тестирование UI - часть QA»? Твои. С этого все и началось.

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

Вобщем иди трезвей, пьянь.

от человека, который не владеет основными терминами и противоречит себе в каждом следующем посте, это звучит особенно мило

и противоречит себе в каждом следующем посте

Ссылки? Конкретно, где я себе противоречу? Твой косяк тебе приведен.

Ссылки? Конкретно, где я себе противоречу?

и да, расскажи как автоматизированное тестирование итогового продукта упрощает рефакторинг и расширение функциональности, а я послушаю

[...]Про UI-тестирование вообще молчу.
Если UI присутствует и жизненный цикл сложнее чем «Если видно значит работает, если не видно значит не работает» - без тестирования представления получится говно.
Найди в оригинальной фразе «включающий в себя полный комплекс мер от автоматическоко тестирования до ручного» аббревиатуру UI. Нету? А с какого перепугу ты его сюда приплел?

сам найдешь противоречие или мне пора переходить на методы общения с наркоманами?

Твой косяк тебе приведен.

чото я его не заметил

сам найдешь противоречие или мне пора переходить на методы общения с наркоманами?

А теперь то же самое в правильной последовательности.

сам найдешь противоречие или мне пора переходить на методы общения с наркоманами?

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

подведем итог

ты понятия не имеешь что такое QA, чем QA отличается от QC и какое место во всем этом занимает тестирование.
ты сначала говоришь о том, что автоматизированные интеграционные тесты - это мастхэв для тестирования UI («Про UI-тестирование вообще молчу»), а потом заявляешь что UI-тесты не имеют отношения к интеграции («Автоматическое тестирование UI - одна из разновидностей юнит-тестов») и к QA вообще (при том, что QA «включающий в себя полный комплекс мер от автоматическоко тестирования до ручного»).
ты не отвечаешь ни на один заданный тебе вопрос, но при этом это мне «пора за слова начать отвечать» и это у меня нет «тени понимания того о чем говоришь».
ты не приводишь абсолютно никаких аргументов, пруфов или хоть сколько-нибудь внятных объяснений, игнорируя при этом цитаты из стандартов и азы, которые известны любому QA, не говоря уже о людях с сертификатами ISTQB выше Foundation level.

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

ты понятия не имеешь что такое QA, чем QA отличается от QC и какое место во всем этом занимает тестирование.

Qualiti Assurance - как дашь ему определение срочно езжай в MIT - там тебе даже за гражданство похлопочут (ну если пустозвоном не назовут).

ты сначала говоришь о том, что автоматизированные интеграционные тесты - это мастхэв для тестирования UI

Да, и я тебе не раз намекал, что тестирование UI выглядит глупым только для <чегонибудь>ml, во всех остальных случаях классы полей ввода кнопок и тому подобных виджетов такие, же самостоятельные сущности как и домой объекты и еже с ними. У них есть свой жизненный цикл за которым желательно следить.

потом заявляешь что UI-тесты не имеют отношения к интеграции

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

ты не отвечаешь ни на один заданный тебе вопрос

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

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

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

Qualiti Assurance - как дашь ему определение срочно езжай в MIT - там тебе даже за гражданство похлопочут (ну если пустозвоном не назовут).

ISO 9000, istqb.org, все определения уже даны давным-давно. но для тебя, как видно, даже это будет открытием.

Да, и я тебе не раз намекал, что тестирование UI выглядит глупым только для <чегонибудь>ml, во всех остальных случаях классы полей ввода кнопок и тому подобных виджетов такие, же самостоятельные сущности как и домой объекты и еже с ними. У них есть свой жизненный цикл за которым желательно следить.

на что тебе не раз отвечали, что это - очевидная вещь. но ты влез с UI-тестами именно в контексте автоматических интеграционных тестов, о чем предпочел забыть после вопроса о связи необходимости тестирования и необходимости тестирования автоматическими интеграционными тестами.

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

да пожалуйста:

проверяющий соответствие логики проекта

чему?

можешь рассказать, какое отношение твой пассаж про необходимость тестирования UI имел к разговору о автоматизированных интеграционных тестах?

потом заявляешь что UI-тесты не имеют отношения к интеграции

Не имеет.

прямо-таки для всех приложений в мире?

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

в интеграционных тестах чего? даю наводку: «тестирование интеграции компонентов (component integration testing): Тестирование, выполняемое для выявления дефектов в интерфейсах и взаимодействии между интегрированными компонентами». интеграцию между какими компонентами ты проверяешь в описанном выше случае?

ISO 9000, istqb.org, все определения уже даны давным-давно. но для тебя, как видно, даже это будет открытием.

Нет, но сейчас еще раз это покурю.

прямо-таки для всех приложений в мире?

О, здравое зерно, перейдем к более «прикладным» определениям?

в интеграционных тестах чего?

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

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

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

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

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